<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="fedregister.xsl"?>
<FEDREG xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FRMergedXML.xsd">
    <VOL>89</VOL>
    <NO>27</NO>
    <DATE>Thursday, February 8, 2024</DATE>
    <UNITNAME>Contents</UNITNAME>
    <CNTNTS>
        <AGCY>
            <EAR>
                Centers Disease
                <PRTPAGE P="iii"/>
            </EAR>
            <HD>Centers for Disease Control and Prevention</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Hearings, Meetings, Proceedings, etc., </DOC>
                    <PGS>8681-8682</PGS>
                    <FRDOCBP>2024-02514</FRDOCBP>
                      
                    <FRDOCBP>2024-02515</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Medicare</EAR>
            <HD>Centers for Medicare &amp; Medicaid Services</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Medicare and Medicaid Programs:</SJ>
                <SJDENT>
                    <SJDOC>Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, etc. on the Federally-Facilitated Exchanges, etc., </SJDOC>
                    <PGS>8758-8988</PGS>
                    <FRDOCBP>2024-00895</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Commerce</EAR>
            <HD>Commerce Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Foreign-Trade Zones Board</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>International Trade Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Oceanic and Atmospheric Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Commodity Futures</EAR>
            <HD>Commodity Futures Trading Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>8651</PGS>
                    <FRDOCBP>2024-02635</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Consumer Product</EAR>
            <HD>Consumer Product Safety Commission</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Safety Standard:</SJ>
                <SJDENT>
                    <SJDOC>Blade-Contact Injuries on Table Saws; Notice of Opportunity for Oral Presentations, </SJDOC>
                    <PGS>8582-8583</PGS>
                    <FRDOCBP>2024-02570</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Residential Gas Furnaces and Boilers, </SJDOC>
                    <PGS>8583-8584</PGS>
                    <FRDOCBP>2024-02563</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Defense Department</EAR>
            <HD>Defense Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Environmental Impact Statements; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>O'Brien Road Access Modernization, Fort Meade, MD, </SJDOC>
                    <PGS>8651-8652</PGS>
                    <FRDOCBP>2024-02612</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Defense Nuclear</EAR>
            <HD>Defense Nuclear Facilities Safety Board</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Recommendation 2023-01, </DOC>
                    <PGS>8652-8666</PGS>
                    <FRDOCBP>2024-02513</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Drug</EAR>
            <HD>Drug Enforcement Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Conforming Amendment Regarding the Veterinary Medicine Mobility Act of 2014, </DOC>
                    <PGS>8538-8539</PGS>
                    <FRDOCBP>2024-02322</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Education Department</EAR>
            <HD>Education Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>President's Board of Advisors on Historically Black Colleges and Universities, </SJDOC>
                    <PGS>8666-8667</PGS>
                    <FRDOCBP>2024-02524</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Energy Department</EAR>
            <HD>Energy Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Energy Regulatory Commission</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Environmental Protection</EAR>
            <HD>Environmental Protection Agency</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>State Hazardous Waste Management Program:</SJ>
                <SJDENT>
                    <SJDOC>South Dakota, </SJDOC>
                    <PGS>8540-8546</PGS>
                    <FRDOCBP>2024-02310</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Definition of Hazardous Waste Applicable to Corrective Action for Releases from Solid Waste Management Units, </DOC>
                    <PGS>8598-8606</PGS>
                    <FRDOCBP>2024-02328</FRDOCBP>
                </DOCENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Unregulated Contaminant Monitoring Rule, </SJDOC>
                    <PGS>8584-8598</PGS>
                    <FRDOCBP>2024-02247</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Listing of Specific Per- and Polyfluoroalkyl Substances as Hazardous Constituents, </DOC>
                    <PGS>8606-8621</PGS>
                    <FRDOCBP>2024-02324</FRDOCBP>
                </DOCENT>
                <SJ>State Hazardous Waste Management Program:</SJ>
                <SJDENT>
                    <SJDOC>South Dakota, </SJDOC>
                    <PGS>8621</PGS>
                    <FRDOCBP>2024-02311</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Air Pollution Regulations for Outer Continental Shelf Activities, </SJDOC>
                    <PGS>8677-8678</PGS>
                    <FRDOCBP>2024-02613</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Climate Pollution Reduction Grants Program Implementation Grants Information Collection Request, </SJDOC>
                    <PGS>8679</PGS>
                    <FRDOCBP>2024-02614</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Cancellation Order for Certain Pesticide Registrations and Amendments to Terminate Uses, </DOC>
                    <PGS>8675</PGS>
                    <FRDOCBP>C1-2023-28547</FRDOCBP>
                </DOCENT>
                <SJ>Exemption:</SJ>
                <SJDENT>
                    <SJDOC>DQB Males (Wolbachia pipientis, DQB Strain, Contained in Live Adult Culex quinquefasciatus Males), </SJDOC>
                    <PGS>8674-8675</PGS>
                    <FRDOCBP>2024-02586</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Pesticides; Flexible Packaging; Child Resistant Packaging Requirements, </DOC>
                    <PGS>8675-8677</PGS>
                    <FRDOCBP>2024-02587</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Aviation</EAR>
            <HD>Federal Aviation Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Falsification, Reproduction, Alteration, Omission, or Incorrect Statements, </DOC>
                    <PGS>8560-8578</PGS>
                    <FRDOCBP>2024-00872</FRDOCBP>
                </DOCENT>
                <DOCENT>
                    <DOC>Modernization of Special Airworthiness Certification, </DOC>
                    <PGS>8559-8560</PGS>
                    <FRDOCBP>2024-02545</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Communications</EAR>
            <HD>Federal Communications Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Video Relay Service and Internet Protocol Captioned Telephone Service—Commencement of Pending User Registration; Rates for Interstate Inmate Calling Services; Correction, </DOC>
                    <PGS>8549</PGS>
                    <FRDOCBP>2024-02384</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Modifying Emissions Limits for the 24.25-24.45 GHz and 24.75-25.25 GHz Bands; Correction, </DOC>
                    <PGS>8621-8622</PGS>
                    <FRDOCBP>2024-02598</FRDOCBP>
                </DOCENT>
                <DOCENT>
                    <DOC>Petition for Reconsideration of Action in Proceeding; Correction, </DOC>
                    <PGS>8621</PGS>
                    <FRDOCBP>2024-02578</FRDOCBP>
                </DOCENT>
                <SJ>Priority Application Review:</SJ>
                <SJDENT>
                    <SJDOC>Broadcast Stations that Provide Local Journalism or Other Locally Originated Programming, </SJDOC>
                    <PGS>8622-8629</PGS>
                    <FRDOCBP>2024-02039</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>8679-8680</PGS>
                    <FRDOCBP>2024-02571</FRDOCBP>
                </DOCENT>
                <SJ>Charter Amendments, Establishments, Renewals and Terminations:</SJ>
                <SJDENT>
                    <SJDOC>World Radiocommunication Conference Advisory Committee, </SJDOC>
                    <PGS>8680-8681</PGS>
                    <FRDOCBP>2024-02619</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Energy</EAR>
            <HD>Federal Energy Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Application:</SJ>
                <SJDENT>
                    <SJDOC>Eagle Creek Schoolfield Hydro, LLC and City of Danville, </SJDOC>
                    <PGS>8668-8669</PGS>
                    <FRDOCBP>2024-02605</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Combined Filings, </DOC>
                    <PGS>8669-8674</PGS>
                    <FRDOCBP>2024-02602</FRDOCBP>
                      
                    <FRDOCBP>2024-02608</FRDOCBP>
                      
                    <FRDOCBP>2024-02609</FRDOCBP>
                </DOCENT>
                <SJ>Environmental Assessments; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Port Arthur Pipeline, LLC, </SJDOC>
                    <PGS>8670-8671</PGS>
                    <FRDOCBP>2024-02607</FRDOCBP>
                </SJDENT>
                <SJ>Initial Market-Based Rate Filings Including Requests for Blanket Section 204 Authorizations:</SJ>
                <SJDENT>
                    <SJDOC>CPV Backbone Solar, LLC, </SJDOC>
                    <PGS>8667-8668</PGS>
                    <FRDOCBP>2024-02604</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                Federal Highway
                <PRTPAGE P="iv"/>
            </EAR>
            <HD>Federal Highway Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>8736-8737</PGS>
                    <FRDOCBP>2024-02572</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Motor</EAR>
            <HD>Federal Motor Carrier Safety Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Request for Information:</SJ>
                <SJDENT>
                    <SJDOC>Study of Sexual Assault and Sexual Harassment in the Commercial Motor Vehicle Industry, </SJDOC>
                    <PGS>8737-8739</PGS>
                    <FRDOCBP>2024-02539</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Railroad</EAR>
            <HD>Federal Railroad Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Emergency Order to Prevent Operation of Trains and Other On-Track Rail Equipment on Blackwell Northern Gateway Railroad, </DOC>
                    <PGS>8739-8741</PGS>
                    <FRDOCBP>2024-02536</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Reserve</EAR>
            <HD>Federal Reserve System</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Change in Bank Control:</SJ>
                <SJDENT>
                    <SJDOC>Acquisitions of Shares of a Bank or Bank Holding Company, </SJDOC>
                    <PGS>8681</PGS>
                    <FRDOCBP>2024-02523</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Trade</EAR>
            <HD>Federal Trade Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Procedures for Oversight of the Horseracing Integrity and Safety Authority's Annual Budget, </DOC>
                    <PGS>8530-8533</PGS>
                    <FRDOCBP>2024-02290</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Horseracing Integrity and Safety Authority Oversight, </DOC>
                    <PGS>8578-8582</PGS>
                    <FRDOCBP>2024-02291</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Transit</EAR>
            <HD>Federal Transit Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Competitive Funding Opportunity:</SJ>
                <SJDENT>
                    <SJDOC>Fiscal Year 2024: Low or No Emission Grant Program and the Grants for Buses and Bus Facilities Competitive Program, </SJDOC>
                    <PGS>8741-8753</PGS>
                    <FRDOCBP>2024-02246</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Fish</EAR>
            <HD>Fish and Wildlife Service</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Endangered and Threatened Species:</SJ>
                <SJDENT>
                    <SJDOC>90-Day Finding for the Kings River Pyrg, </SJDOC>
                    <PGS>8629-8631</PGS>
                    <FRDOCBP>2024-02620</FRDOCBP>
                </SJDENT>
                <SJ>Migratory Bird Hunting:</SJ>
                <SJDENT>
                    <SJDOC>Proposed 2024-25 Migratory Game Bird Hunting Regulations, </SJDOC>
                    <PGS>8631-8639</PGS>
                    <FRDOCBP>2024-02517</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Western Snowy Plover Survey and Reporting, </SJDOC>
                    <PGS>8703-8705</PGS>
                    <FRDOCBP>2024-02569</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Food and Drug</EAR>
            <HD>Food and Drug Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Filing of Petition:</SJ>
                <SJDENT>
                    <SJDOC>Color Additive; Sensient Colors, LLC, </SJDOC>
                    <PGS>8537-8538</PGS>
                    <FRDOCBP>2024-02576</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>8682</PGS>
                    <FRDOCBP>2024-02579</FRDOCBP>
                </DOCENT>
                <SJ>International Drug Scheduling:</SJ>
                <SJDENT>
                    <SJDOC>Convention on Psychotropic Substances; Single Convention on Narcotic Drugs; World Health Organization; Scheduling Recommendations; Butonitazene; 3-Chloromethcathinone; Dipentylone; 2-Fluorodeschloroketamine; Bromazolam, </SJDOC>
                    <PGS>8683-8689</PGS>
                    <FRDOCBP>2024-02573</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Foreign Assets</EAR>
            <HD>Foreign Assets Control Office</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Sanctions Action, </DOC>
                    <PGS>8753-8754</PGS>
                    <FRDOCBP>2024-02240</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Foreign Trade</EAR>
            <HD>Foreign-Trade Zones Board</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Board Proceedings, </DOC>
                    <PGS>8525-8530</PGS>
                    <FRDOCBP>2024-01953</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Geological</EAR>
            <HD>Geological Survey</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Landslide Hazards Risk Reduction Grants Program, </SJDOC>
                    <PGS>8705-8706</PGS>
                    <FRDOCBP>2024-02589</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Panhandle Terrapin Project, </SJDOC>
                    <PGS>8706-8707</PGS>
                    <FRDOCBP>2024-02591</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Government Accountability</EAR>
            <HD>Government Accountability Office</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Government Auditing Standard; 2024 Revision, </DOC>
                    <PGS>8681</PGS>
                    <FRDOCBP>2024-02594</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Health and Human</EAR>
            <HD>Health and Human Services Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Centers for Disease Control and Prevention</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Centers for Medicare &amp; Medicaid Services</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Food and Drug Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Institutes of Health</P>
            </SEE>
            <CAT>
                <HD>RULES</HD>
                <SJ>Health Data, Technology, and Interoperability:</SJ>
                <SJDENT>
                    <SJDOC>Certification Program Updates, Algorithm Transparency, and Information Sharing; Correction, </SJDOC>
                    <PGS>8546-8549</PGS>
                    <FRDOCBP>2024-02519</FRDOCBP>
                </SJDENT>
                <SJ>Medicare and Medicaid Programs:</SJ>
                <SJDENT>
                    <SJDOC>Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, etc. on the Federally-Facilitated Exchanges, etc., </SJDOC>
                    <PGS>8758-8988</PGS>
                    <FRDOCBP>2024-00895</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Homeland</EAR>
            <HD>Homeland Security Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Transportation Security Administration</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Civil Rights Evaluation Tool, </SJDOC>
                    <PGS>8692-8693</PGS>
                    <FRDOCBP>2024-02588</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Housing</EAR>
            <HD>Housing and Urban Development Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Privacy Act; Matching Program, </DOC>
                    <PGS>8693-8703</PGS>
                    <FRDOCBP>2024-02566</FRDOCBP>
                      
                    <FRDOCBP>2024-02567</FRDOCBP>
                      
                    <FRDOCBP>2024-02568</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Indian Affairs</EAR>
            <HD>Indian Affairs Bureau</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Rate Adjustments for Indian Irrigation Projects, </DOC>
                    <PGS>8707-8712</PGS>
                    <FRDOCBP>2024-02596</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Interior</EAR>
            <HD>Interior Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Fish and Wildlife Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Geological Survey</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Indian Affairs Bureau</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Park Service</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Internal Revenue</EAR>
            <HD>Internal Revenue Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>8755</PGS>
                    <FRDOCBP>2024-02575</FRDOCBP>
                </DOCENT>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Pre-Approved Plans Program, </SJDOC>
                    <PGS>8754-8755</PGS>
                    <FRDOCBP>2024-02574</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>International Trade Adm</EAR>
            <HD>International Trade Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Antidumping or Countervailing Duty Investigations, Orders, or Reviews, </DOC>
                    <PGS>8641-8649</PGS>
                    <FRDOCBP>2024-02600</FRDOCBP>
                </DOCENT>
                <SJ>Sales at Less Than Fair Value; Determinations, Investigations, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Truck and Bus Tires from Thailand, </SJDOC>
                    <PGS>8649</PGS>
                    <FRDOCBP>2024-02601</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                Justice Department
                <PRTPAGE P="v"/>
            </EAR>
            <HD>Justice Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Drug Enforcement Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Labor Department</EAR>
            <HD>Labor Department</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Practice and Procedure, </DOC>
                    <PGS>8533-8537</PGS>
                    <FRDOCBP>2024-01991</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Archives</EAR>
            <HD>National Archives and Records Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>State, Local, Tribal, and Private Sector Policy Advisory Committee, </SJDOC>
                    <PGS>8724-8725</PGS>
                    <FRDOCBP>2024-02529</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Institute</EAR>
            <HD>National Institutes of Health</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Center for Scientific Review, </SJDOC>
                    <PGS>8690</PGS>
                    <FRDOCBP>2024-02581</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Eunice Kennedy Shriver National Institute of Child Health and Human Development, </SJDOC>
                    <PGS>8691-8692</PGS>
                    <FRDOCBP>2024-02525</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Cancer Institute, </SJDOC>
                    <PGS>8689-8691</PGS>
                    <FRDOCBP>2024-02592</FRDOCBP>
                      
                    <FRDOCBP>2024-02593</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of General Medical Sciences, </SJDOC>
                    <PGS>8690</PGS>
                    <FRDOCBP>2024-02582</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute on Aging, </SJDOC>
                    <PGS>8690</PGS>
                    <FRDOCBP>2024-02583</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute on Drug Abuse, </SJDOC>
                    <PGS>8691</PGS>
                    <FRDOCBP>2024-02526</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Oceanic</EAR>
            <HD>National Oceanic and Atmospheric Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Fisheries of the Northeastern United States:</SJ>
                <SJDENT>
                    <SJDOC>Atlantic Deep-Sea Red Crab Fishery; 2024 Atlantic Deep-Sea Red Crab Specifications, </SJDOC>
                    <PGS>8557-8558</PGS>
                    <FRDOCBP>2024-02516</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Regulations Governing the Take of Marine Mammals Incidental to Specified Activities; CFR Correction, </DOC>
                    <PGS>8557</PGS>
                    <FRDOCBP>2024-02695</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Fisheries of the Caribbean, Gulf of Mexico, and South Atlantic:</SJ>
                <SJDENT>
                    <SJDOC>Atlantic Coastal Migratory Pelagic Fishery; Atlantic Dolphin and Wahoo Fishery; and South Atlantic Snapper-Grouper Fishery; Control Date, </SJDOC>
                    <PGS>8639-8640</PGS>
                    <FRDOCBP>2024-02509</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Gulf of Mexico Fishery Management Council, </SJDOC>
                    <PGS>8650-8651</PGS>
                    <FRDOCBP>2024-02616</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>North Pacific Fishery Management Council, </SJDOC>
                    <PGS>8650</PGS>
                    <FRDOCBP>2024-02617</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Pacific Fishery Management Council, </SJDOC>
                    <PGS>8651</PGS>
                    <FRDOCBP>2024-02615</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Park</EAR>
            <HD>National Park Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Procedures for State, Tribal, and Local Government Historic Preservation Programs and Management of Historic Preservation Fund Grants, </SJDOC>
                    <PGS>8713-8714</PGS>
                    <FRDOCBP>2024-02584</FRDOCBP>
                </SJDENT>
                <SJ>Inventory Completion:</SJ>
                <SJDENT>
                    <SJDOC>Central Washington University, Ellensburg, WA, </SJDOC>
                    <PGS>8719-8720</PGS>
                    <FRDOCBP>2024-02550</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve, Glen Cove, NY, </SJDOC>
                    <PGS>8715-8716</PGS>
                    <FRDOCBP>2024-02559</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Ohio History Connection, Columbus, OH, </SJDOC>
                    <PGS>8712-8718, 8721-8724</PGS>
                    <FRDOCBP>2024-02551</FRDOCBP>
                      
                    <FRDOCBP>2024-02552</FRDOCBP>
                      
                    <FRDOCBP>2024-02553</FRDOCBP>
                      
                    <FRDOCBP>2024-02554</FRDOCBP>
                      
                    <FRDOCBP>2024-02555</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Peabody Museum of Archaeology and Ethnology, Harvard University, Cambridge, MA, </SJDOC>
                    <PGS>8720</PGS>
                    <FRDOCBP>2024-02557</FRDOCBP>
                </SJDENT>
                <SJ>Repatriation of Cultural Items:</SJ>
                <SJDENT>
                    <SJDOC>Central Washington University, Ellensburg, WA, </SJDOC>
                    <PGS>8718-8719</PGS>
                    <FRDOCBP>2024-02549</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Goucher College, Baltimore, MD, </SJDOC>
                    <PGS>8722-8723</PGS>
                    <FRDOCBP>2024-02558</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>University of California, Berkeley, Berkeley, CA, </SJDOC>
                    <PGS>8721</PGS>
                    <FRDOCBP>2024-02556</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Nuclear Regulatory</EAR>
            <HD>Nuclear Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Licenses; Exemptions, Applications, Amendments etc.:</SJ>
                <SJDENT>
                    <SJDOC>Tennessee Valley Authority; Browns Ferry Nuclear Plant, Units 1, 2, and 3, </SJDOC>
                    <PGS>8725</PGS>
                    <FRDOCBP>2024-02611</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Pension Benefit</EAR>
            <HD>Pension Benefit Guaranty Corporation</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Locating and Paying Participants, </SJDOC>
                    <PGS>8725-8726</PGS>
                    <FRDOCBP>2024-02518</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Postal Regulatory</EAR>
            <HD>Postal Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>New Postal Products, </DOC>
                    <PGS>8726-8728</PGS>
                    <FRDOCBP>2024-02527</FRDOCBP>
                      
                    <FRDOCBP>2024-02618</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Postal Service</EAR>
            <HD>Postal Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Product Change:</SJ>
                <SJDENT>
                    <SJDOC>Priority Mail and USPS Ground Advantage Negotiated Service Agreement, </SJDOC>
                    <PGS>8728-8730</PGS>
                    <FRDOCBP>2024-02540</FRDOCBP>
                      
                    <FRDOCBP>2024-02541</FRDOCBP>
                      
                    <FRDOCBP>2024-02542</FRDOCBP>
                      
                    <FRDOCBP>2024-02530</FRDOCBP>
                      
                    <FRDOCBP>2024-02531</FRDOCBP>
                      
                    <FRDOCBP>2024-02532</FRDOCBP>
                      
                    <FRDOCBP>2024-02534</FRDOCBP>
                      
                    <FRDOCBP>2024-02537</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Priority Mail Express, Priority Mail, and USPS Ground Advantage Negotiated Service Agreement, </SJDOC>
                    <PGS>8728, 8730</PGS>
                    <FRDOCBP>2024-02538</FRDOCBP>
                      
                    <FRDOCBP>2024-02543</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Priority Mail Express, Priority Mail, USPS Ground Advantage, and Parcel Select Negotiated Service Agreement, </SJDOC>
                    <PGS>8728</PGS>
                    <FRDOCBP>2024-02533</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Priority Mail, USPS Ground Advantage and Parcel Select Negotiated Service Agreement, </SJDOC>
                    <PGS>8729</PGS>
                    <FRDOCBP>2024-02535</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Securities</EAR>
            <HD>Securities and Exchange Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Self-Regulatory Organizations; Proposed Rule Changes:</SJ>
                <SJDENT>
                    <SJDOC>Fixed Income Clearing Corp., </SJDOC>
                    <PGS>8730-8732</PGS>
                    <FRDOCBP>2024-02520</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Small Business</EAR>
            <HD>Small Business Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Disaster Declaration:</SJ>
                <SJDENT>
                    <SJDOC>Maine, </SJDOC>
                    <PGS>8734</PGS>
                    <FRDOCBP>2024-02561</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Maine; Public Assistance Only, </SJDOC>
                    <PGS>8735</PGS>
                    <FRDOCBP>2024-02560</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>New York; Public Assistance Only, </SJDOC>
                    <PGS>8733-8734</PGS>
                    <FRDOCBP>2024-02546</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>North Carolina, </SJDOC>
                    <PGS>8733</PGS>
                    <FRDOCBP>2024-02547</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Tennessee; Public Assistance Only, </SJDOC>
                    <PGS>8733</PGS>
                    <FRDOCBP>2024-02564</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>West Virginia, </SJDOC>
                    <PGS>8734-8735</PGS>
                    <FRDOCBP>2024-02548</FRDOCBP>
                </SJDENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Veterans Business Affairs, </SJDOC>
                    <PGS>8735-8736</PGS>
                    <FRDOCBP>2024-02599</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Interagency Task Force on Veterans Small Business Development, </SJDOC>
                    <PGS>8732-8733</PGS>
                    <FRDOCBP>2024-02597</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>State Department</EAR>
            <HD>State Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>International Security Advisory Board, </SJDOC>
                    <PGS>8736</PGS>
                    <FRDOCBP>2024-02606</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Transportation Department</EAR>
            <HD>Transportation Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Aviation Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Highway Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Motor Carrier Safety Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Railroad Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Transit Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Security</EAR>
            <HD>Transportation Security Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Frequency of Renewal Cycle for Indirect Air Carrier Security Programs, </DOC>
                    <PGS>8550-8557</PGS>
                    <FRDOCBP>2024-02495</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Treasury</EAR>
            <HD>Treasury Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Foreign Assets Control Office</P>
            </SEE>
            <SEE>
                <PRTPAGE P="vi"/>
                <HD SOURCE="HED">See</HD>
                <P>Internal Revenue Service</P>
            </SEE>
        </AGCY>
        <PTS>
            <HD SOURCE="HED">Separate Parts In This Issue</HD>
            <HD>Part II</HD>
            <DOCENT>
                <DOC>Health and Human Services Department, Centers for Medicare &amp; Medicaid Services, </DOC>
                <PGS>8758-8988</PGS>
                <FRDOCBP>2024-00895</FRDOCBP>
            </DOCENT>
            <DOCENT>
                <DOC>Health and Human Services Department, </DOC>
                <PGS>8758-8988</PGS>
                <FRDOCBP>2024-00895</FRDOCBP>
            </DOCENT>
        </PTS>
        <AIDS>
            <HD SOURCE="HED">Reader Aids</HD>
            <P>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.</P>
            <P>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.</P>
        </AIDS>
    </CNTNTS>
    <VOL>89</VOL>
    <NO>27</NO>
    <DATE>Thursday, February 8, 2024</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <RULES>
        <RULE>
            <PREAMB>
                <PRTPAGE P="8525"/>
                <AGENCY TYPE="F">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>Foreign-Trade Zones Board</SUBAGY>
                <CFR>15 CFR Part 400</CFR>
                <DEPDOC>[Docket No. 240111-0015; Order No. 2157]</DEPDOC>
                <RIN>RIN 0625-AB22</RIN>
                <SUBJECT>Foreign-Trade Zones Board Proceedings</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Foreign-Trade Zones Board, International Trade Administration, Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This action adopts minor modifications to the regulations of the Foreign-Trade Zones Board (the Board). The primary purpose for these modifications is to provide flexibility on the method to submit application fees. The prior regulations required submitting application fees by check. The changes allow for the submission of multiple forms of electronic payments in addition to paper checks. Other revisions in this rulemaking update the regulatory language to provide clarification and to reflect current practices. The Board is also confirming it has met the information collection requirements from a 2012 final rule.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">Effective dates:</E>
                         This final rule is effective March 11, 2024.
                    </P>
                    <P>The amendments to 15 CFR 400.21 through 400.23, 400.25, and 400.43(f), published at 77 FR 12139 (Feb. 28, 2012), are effective February 8, 2024.</P>
                    <P>
                        <E T="03">Applicability date:</E>
                         The amendments to 15 CFR 400.21 through 400.23, 400.25, and 400.43(f), published at 77 FR 12139 (Feb. 28, 2012), were applicable beginning March 25, 2013.
                    </P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Elizabeth Whiteman at 
                        <E T="03">Elizabeth.Whiteman@trade.gov,</E>
                         (202) 482-0473, or Ashlande Gelin at 
                        <E T="03">Ashlande.Gelin@trade.gov,</E>
                         (240) 449-5911.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    Foreign-Trade Zones (FTZs or zones) are restricted-access sites in or near U.S. Customs and Border Protection (CBP) ports of entry. Zones are licensed by the Board and operated under the supervision of CBP (
                    <E T="03">see</E>
                     19 CFR part 146). Specifically, zones are physical areas into which foreign and domestic merchandise may be moved for operations involving storage, exhibition, assembly, manufacture or other processing not otherwise prohibited by law. Zone areas “activated” by CBP are considered outside of U.S. customs territory for purposes of CBP entry procedures. Therefore, the usual formal CBP entry procedure and payment of duties is not required on the foreign merchandise in FTZs unless and until it enters U.S. customs territory for U.S. domestic consumption. In fact, U.S. duties can be avoided on foreign merchandise re-exported from an FTZ, including after incorporation into a downstream product through activity in the FTZ. Zones have as their public policy objective the creation and maintenance of employment through the encouragement of operations in the United States which, for customs reasons, might otherwise have been carried on abroad.
                </P>
                <P>On June 9, 2023, the Board published proposed updates to the rules for FTZs and requested public comment (88 FR 37815). This final rule adopts edits to the regulations as described further below. The key revision in the regulations pertains to providing flexibility on the method to submit application fees. The prior regulations required that application fees be submitted by check. While the Board has begun accepting “eChecks”, the revisions here will allow for the submission of additional forms of electronic payment.</P>
                <P>This action will move the existing requirement to admit merchandise subject to antidumping duty and countervailing duty (AD/CVD) actions in “privileged foreign” (PF) status to the “General conditions, prohibitions and restrictions applicable to authorized zones” section. This move of the existing language is intended to clarify that the provision applies to all merchandise that is admitted to FTZs.</P>
                <P>Other revisions in this rulemaking update the language used to provide clarification and to reflect current practices.</P>
                <P>On February 28, 2012, a final rule was published revising the regulations of the Foreign-Trade Zones Board (77 FR 12112). That rule was published with an effective date of April 30, 2012, except for sections 400.21-400.23, 400.25 and 400.43(f). These sections contained information collection requirements and could not become effective until the Office of Management and Budget (OMB) approved these information collection requests pursuant to the Paperwork Reduction Act (44 U.S.C. Chapter 35). On March 25, 2013, OMB approved the information collections under control number 0625-0139, and the FTZ Board then began to use the new applications under sections 400.21-400.23, 400.25 and 400.43(f). This rulemaking also confirms the information collection requirements from the 2012 final rule were met.</P>
                <HD SOURCE="HD1">Comments and Responses</HD>
                <P>We received nine comments on the proposed rule from five companies operating FTZs, two zone grantees, a law firm and a trade association. The comments involved several of the edits described in the proposed rulemaking and also suggested additional edits to the regulations. The comments received in response to the notice and the Board's responses on the points raised in the comments are summarized below.</P>
                <P>
                    <E T="03">Comment 1:</E>
                     §§ 400.1(c) and 400.16. One comment stated that the word “production” should be added to the list of activities in §§ 400.1(c) and 400.16.
                </P>
                <P>
                    <E T="03">Response:</E>
                     The Board adopted the word “production” in its 2012 regulations to encompass various activities that require prior authorization from the Board. By using the word production, the Board was not creating a new type of activity that could occur within FTZs. The summary lists in both §§ 400.1(c) and 400.16 use common terminology to describe the types of activity that can occur within FTZs. Instead of creating a new type of activity to be added to these lists, “production” as defined in the regulations (§ 400.2(o)) could include any of the listed activities if they meet the criteria included in the definition. Inclusion of the word production in the lists in these sections could provide the mistaken impression that “production” is a separate activity from the other 
                    <PRTPAGE P="8526"/>
                    items listed. As a result, this change has not been adopted.
                </P>
                <P>
                    <E T="03">Comment 2:</E>
                     § 400.2. One comment suggested that a definition be included for “Traditional Site Framework”.
                </P>
                <P>
                    <E T="03">Response:</E>
                     While we agree that a definition for the Traditional Site Framework should be included in the regulations in the future, any definition should provide substance. Creating a definition that is both meaningful and substantive will require additional time and is best suited for another rulemaking.
                </P>
                <P>
                    <E T="03">Comment 3:</E>
                     § 400.11(b)(2)(i). One comment requested confirmation that removing the phrase “general purpose” from the description of zone sites in § 400.11(b)(2)(i) would not impact the adjacency requirement for subzones in § 400.11(b)(2)(ii).
                </P>
                <P>
                    <E T="03">Response:</E>
                     We can confirm that removal of the phrase “general purpose” from § 400.11(b)(2)(i) will not impact § 400.11(b)(2)(ii).
                </P>
                <P>
                    <E T="03">Comment 4:</E>
                     § 400.13(a)(8). One comment requested confirmation that the proposed edits to § 400.13(a)(8) would continue to require that grantees maintain a level of control while providing discretion to the grantee on how to maintain that control over FTZ designated locations.
                </P>
                <P>
                    <E T="03">Response:</E>
                     We can confirm that the edit proposed here would continue to require that the grantee maintain control over FTZ designated sites and subzones but that a grantee will have flexibility and discretion as to how control is maintained. The regulations will no longer require that a grantee maintain an agreement with a property owner.
                </P>
                <P>
                    <E T="03">Comment 5:</E>
                     § 400.13(c). One comment stated that moving prior § 400.14(e) to § 400.13(c) could have an adverse effect on warehouse operations, not be consistent with 19 U.S.C. 81(c)(e) and should only be considered through a more involved process.
                </P>
                <P>
                    <E T="03">Response:</E>
                     This comment did not supply any evidence in support of the statements made. The language to be moved from § 400.14(e) to § 400.13(c) has been included as part of the FTZ Board's regulations since 1991. Since 1991, merchandise admitted to FTZs that is subject to AD/CVD orders or suspension of liquidation under AD/CVD procedures has been required to be placed in PF status (19 CFR 146.41) regardless of the ultimate use of the merchandise in production or warehousing operations. As a result, moving the language from § 400.14(e) to § 400.13(c) will have no impact on warehouse operators or any existing zone operations. While the production equipment provision of the FTZ Act (19 U.S.C. 81(c)(e)) generally allows for duties on eligible merchandise to be paid in its condition upon entry, the Act first requires that all other applicable customs and other laws be applied. The Act does not provide for unconditional use of the production equipment provision in 19 U.S.C. 81(c)(e).
                </P>
                <P>
                    The change proposed here simply moves the existing language from one section of the regulations to the prior section. The change is being made since including the language in § 400.13(c) better reflects the existing interpretation of the requirement. The PF status requirement for merchandise that is subject to AD/CVD orders or suspension of liquidation under AD/CVD procedures when admitted to a zone for warehousing or for use under the production equipment provision has been consistently maintained. As an example, a memo from the Acting Executive Secretary to FTZ grantees on February 14, 2000 (
                    <E T="03">https://www.trade.gov/policy-guidance?anchor=content-node-t14-field-lp-region-1-3</E>
                    ) regarding the treatment of production equipment includes the following: “The equipment should be evaluated for Customs duty purposes in its condition when it goes into production (
                    <E T="03">i.e.,</E>
                     as complete production equipment), keeping in mind the requirements for evaluating incoming articles subject to antidumping/countervailing (AD/CVD) orders. The FTZ regulations require the election of privileged foreign status, upon admission to the zone, on any incoming merchandise that is subject to AD/CVD orders . . . When such merchandise leaves the zone for U.S. commerce, it will be subject to AD/CVD procedures based on its condition when it arrived at the zone.”
                </P>
                <P>Since this proposed edit does not change the enforcement or meaning of the language; this action merely moves the existing language from § 400.14(e) to § 400.13(c).</P>
                <P>
                    <E T="03">Comment 6:</E>
                     § 400.13(c) and § 400.32(c)(2). One comment suggested including reference to Chapter 99 (trade remedy) duty rates in § 400.13(c) and § 400.32(c)(2) and specifying the duty rate that would be applicable for such merchandise at the time of entry from a zone. This comment also suggested including a new section of the regulations regarding merchandise processed in a zone and subject to Chapter 99 duties.
                </P>
                <P>
                    <E T="03">Response:</E>
                     Although it is understood that the intention of this comment is to provide predictability to companies operating and using FTZs, this proposed edit could impact multiple laws involving trade remedies. Inclusion of this language would remove the relevant authorities regarding trade remedies from decisions on the applicability of duties as merchandise leaves FTZs, potentially having policy implications and impacting various trade remedy actions. While the comment noted that inclusion of the proposed language would be consistent with certain presidential proclamations regarding trade remedies, the proposed language would not be consistent with all proclamations regarding current trade remedies. As a result, the proposed edits related to Chapter 99 duties would require further review and discussion and therefore are not appropriate for this process.
                </P>
                <P>
                    <E T="03">Comment 7:</E>
                     § 400.16. Several comments argued that the proposed addition of the phrase “in foreign status” to § 400.16 would be inconsistent with the statutory language of 19 U.S.C. 81(o)(e) and that a similar proposed regulatory change in 1990 resulted in the FTZ Board revising its final regulations. One comment also requested clarification on the practical implications of including the phrase “in the activated area” in this section. Other comments supported inclusion of the phrase “in the activated area” in this section.
                </P>
                <P>
                    <E T="03">Response:</E>
                     In response to the comments received, this action replaces the proposed phrase “in foreign status” with a reference to “foreign merchandise”. Use of the modifier “foreign” to describe merchandise in this section is consistent with the language adopted by the Board in 1991 and currently used in § 400.1(c) as well.
                </P>
                <P>
                    While the substance of the comments is not being analyzed through this process, the discussion and outcome of the regulatory edits in 1991 does not appear to be as settled as implied in the comments. In 1990, the Board proposed including language to § 400.1(c) stating that merchandise should be in the zone for a 
                    <E T="03">bona fide</E>
                     customs reason to be eligible for the exemption on state and local 
                    <E T="03">ad valorem</E>
                     taxes. While the language was ultimately removed from the final rule in 1991, the preamble to the 1991 regulations included the following reference to language in the House report accompanying Public Law 98-873: “. . . this exemption should apply only to goods in zones for 
                    <E T="03">bona fide</E>
                     Customs reasons.” This action continues use of the reference to merchandise eligible for the exemption on state and local 
                    <E T="03">ad valorem</E>
                     taxes as “foreign”. Further edits or changes to this language would only be considered as part of more comprehensive regulatory revisions that would provide for further comment and analysis.
                    <PRTPAGE P="8527"/>
                </P>
                <P>
                    In terms of the reference to “in the activated area” in this section, we can confirm that this would clarify that FTZ designated space would need to be in operation and activated under CBP procedures for the merchandise to be exempt from state and local 
                    <E T="03">ad valorem</E>
                     taxes. Inclusion of this language provides clarification on the long-standing Board interpretation and is not a new requirement or limitation on this section. Apart from one comment requesting clarification, all other comments supported inclusion of this phrase.
                </P>
                <HD SOURCE="HD1">Changes From the Proposed Rule</HD>
                <P>The sole change to the regulatory text from the proposed rule is replacing the proposed phrase “foreign status” with “foreign” in § 400.16. The change to this text is consistent with the language adopted by the Board in 1991 and currently used in § 400.1(c). As a result, this change does not require additional public comment.</P>
                <HD SOURCE="HD1">Classification</HD>
                <P>This final rule has been determined to be not significant for purposes of Executive Order 12866.</P>
                <P>The Chief Counsel for Regulation of the Department of Commerce certified to the Chief Counsel for Advocacy of the Small Business Administration during the proposed rule stage that this action would not have a significant economic impact on a substantial number of small entities. The factual basis for the certification was published in the proposed rule and is not repeated here. No comments were received regarding this certification. As a result, a regulatory flexibility analysis was not required and none was prepared.</P>
                <P>This final rule contains no new information collection requirements under the Paperwork Reduction Act of 1995.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 15 CFR Part 400</HD>
                    <P>Administrative practice and procedure, Confidential business information, Customs duties and inspection, Foreign-trade zones, Harbors, Imports, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: January 26, 2024.</DATED>
                    <NAME>Dawn Shackleford,</NAME>
                    <TITLE>Executive Director of Trade Agreements Policy &amp; Negotiations, Alternate Chairman, Foreign-Trade Zones Board.</TITLE>
                </SIG>
                <P>For the reasons set out in the preamble, 15 CFR part 400 is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 400—REGULATIONS OF THE FOREIGN-TRADE ZONES BOARD</HD>
                </PART>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>1. The authority citation for part 400 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>Foreign-Trade Zones Act of June 18, 1934, as amended (Pub. L. 73-397, 48 Stat. 998-1003 (19 U.S.C. 81a-81u)).</P>
                    </AUTH>
                </REGTEXT>
                  
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>2. In § 400.2:</AMDPAR>
                    <AMDPAR>a. Revise paragraphs (h) and (t);</AMDPAR>
                    <AMDPAR>b. Remove paragraph (u); and</AMDPAR>
                    <AMDPAR>c. Redesignate paragraphs (v) through (aa) as paragraphs (u) through (z).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.2 </SECTNO>
                        <SUBJECT> Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            (h) 
                            <E T="03">Foreign-trade zone</E>
                             (FTZ or zone) includes all sites/subzones designated under the sponsorship of a zone grantee, in or adjacent (as defined by § 400.11(b)(2)) to a CBP port of entry, operated as a public utility (within the meaning of § 400.42), with zone operations under the supervision of CBP.
                        </P>
                        <STARS/>
                        <P>
                            (t) 
                            <E T="03">Usage-driven site</E>
                             means a site established for a single operator or user under the ASF.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>3. In § 400.4, revise paragraphs (m) and (t) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.4 </SECTNO>
                        <SUBJECT>Authority and responsibilities of the Executive Secretary.</SUBJECT>
                        <STARS/>
                        <P>(m) Issue instructions, guidelines, forms and related documents specifying time, place, manner and formats for applications, notifications, application fees and zone schedules in various sections of this part, including §§ 400.21(b), 400.29, 400.43(f), and 400.44;</P>
                        <STARS/>
                        <P>(t) Review zone schedules and determine their sufficiency under § 400.44(c);</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>4. In § 400.11, revise paragraph (b)(2)(i) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.11 </SECTNO>
                        <SUBJECT>Number and location of zones and subzones.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(2) * * *</P>
                        <P>(i) A zone site is located within 60 statute miles or 90 minutes' driving time (as determined or concurred upon by CBP) from the outer limits of a port of entry boundary as defined in 19 CFR 101.3.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>5. In § 400.13:</AMDPAR>
                    <AMDPAR>a. Revise paragraph (a)(8);</AMDPAR>
                    <AMDPAR>b. Redesignate paragraph (c) as paragraph (d); and</AMDPAR>
                    <AMDPAR>c. Add a new paragraph (c).</AMDPAR>
                    <P>The revision and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.13 </SECTNO>
                        <SUBJECT>General conditions, prohibitions and restrictions applicable to authorized zones.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(8) Private ownership of zone land and facilities is permitted, provided the zone grantee retains the control necessary to implement the approved zone. Such permission shall not constitute a vested right to zone designation, nor interfere with the Board's regulation of the grantee or the permittee, nor interfere with or complicate the revocation of the grant by the Board. Grantees shall retain a level of control which allows the grantee to carry out its responsibilities as grantee. The sale of zone-designated land/facility for more than its fair market value without zone designation could, depending on the circumstances, be subject to the prohibitions set forth in section 17 of the Act (19 U.S.C. 81q).</P>
                        <STARS/>
                        <P>
                            (c) 
                            <E T="03">Restrictions on items subject to antidumping and countervailing duty actions</E>
                            —(1) 
                            <E T="03">Board policy.</E>
                             Zone procedures shall not be used to circumvent antidumping duty (AD) and countervailing duty (CVD) actions under 19 CFR part 351.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Admission of items subject to AD/CVD actions.</E>
                             Items subject to AD/CVD orders, or items which would be otherwise subject to suspension of liquidation under AD/CVD procedures if they entered U.S. customs territory, shall be placed in privileged foreign status (19 CFR 146.41) upon admission to a zone or subzone. Upon entry for consumption, such items shall be subject to duties under AD/CVD orders or to suspension of liquidation, as appropriate, under 19 CFR part 351.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>6. In § 400.14:</AMDPAR>
                    <AMDPAR>a. Revise the section heading and paragraph (a); and</AMDPAR>
                    <AMDPAR>b. Remove paragraph (e).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.14 </SECTNO>
                        <SUBJECT>Production—requirement for prior authorization.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">In general.</E>
                             Production activity in zones shall not be conducted without prior authorization from the Board. To obtain authorization, the notification process provided for in §§ 400.22 and 400.37 shall be used. If Board review of a notification under § 400.37 results in a determination that further review is warranted for all or part of the notified activity, the application process pursuant to §§ 400.23, 400.31 through 400.32, 400.34, and 400.36 shall apply 
                            <PRTPAGE P="8528"/>
                            to the activity. Notifications and applications requesting production authority may be submitted by the zone's grantee or by the operator that proposes to undertake the activity (provided the operator at the same time furnishes a copy of the notification or application to the grantee and that submissions by the operator are consistent with the grantee's zone schedule).
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>7. Revise § 400.16 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.16 </SECTNO>
                        <SUBJECT>
                            Exemption from state and local 
                            <E T="0714">ad valorem</E>
                             taxation of tangible personal property.
                        </SUBJECT>
                        <P>
                            Foreign merchandise (tangible personal property) imported from outside the United States and held in the activated area of a zone for the purpose of storage, sale, exhibition, repackaging, assembly, distribution, sorting, grading, cleaning, mixing, display, manufacturing, or processing, and tangible personal property produced in the United States and held in the activated area of a zone for exportation, either in its original form or as altered by any of the processes set out in this section, shall be exempt from state and local 
                            <E T="03">ad valorem</E>
                             taxation.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>8. In § 400.21:</AMDPAR>
                    <AMDPAR>a. Revise paragraphs (a) and (c)(1);</AMDPAR>
                    <AMDPAR>b. In paragraph (c)(5), add the word “and” following the semicolon;</AMDPAR>
                    <AMDPAR>c. Remove paragraph (c)(6) and redesignate paragraph (c)(7) as paragraph (c)(6);</AMDPAR>
                    <AMDPAR>d. Remove paragraph (d)(2)(vi);</AMDPAR>
                    <AMDPAR>e. Redesignate paragraphs (d)(2)(vii) and (ix) as paragraphs (d)(2)(vi) through (viii);</AMDPAR>
                    <AMDPAR>f. Revise paragraphs (e)(3), (h), and (i); and</AMDPAR>
                    <AMDPAR>g. Remove paragraph (j).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.21 </SECTNO>
                        <SUBJECT>Application to establish a zone.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">In general.</E>
                             An application for a grant of authority to establish a zone (including pursuant to the ASF procedures adopted by the Board (§ 400.2(c))) shall consist of an application letter and detailed contents to meet the requirements of this part.
                        </P>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>(1) The relationship of the proposal to the state enabling legislation and the applicant's charter;</P>
                        <STARS/>
                        <P>(e) * * *</P>
                        <P>(3) Appropriate information regarding usage-driven sites or ASF subzones.</P>
                        <STARS/>
                        <P>
                            (h) 
                            <E T="03">Drafts.</E>
                             Applicants are encouraged to submit a draft application to the Executive Secretary for review. A draft application must be complete with the possible exception of the application letter and/or resolution from the applicant.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Submission of completed application.</E>
                             The applicant shall submit the complete application, including all attachments, via email or by the method prescribed by the Executive Secretary pursuant to § 400.4(m).
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>9. In § 400.24, revise paragraphs (a)(1), (c), and (d) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.24 </SECTNO>
                        <SUBJECT>Application for expansion or other modification to zone.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(1) A grantee may apply to the Board for authority to expand or otherwise modify its zone (including pursuant to the ASF procedures adopted by the Board (§ 400.2(c))).</P>
                        <STARS/>
                        <P>
                            (c) 
                            <E T="03">Minor modification to zone.</E>
                             Other applications or requests under this subpart shall be submitted in letter form with information and documentation necessary for analysis, as determined by the Executive Secretary, who shall determine whether the proposed change is a minor one subject to this paragraph (c) instead of paragraph (b) of this section (
                            <E T="03">see</E>
                             § 400.38). Such applications or requests include those for minor revisions of zone or subzone boundaries based on immediate need, as well as for designation as a subzone of all or part of an existing zone site(s) (or site(s) that qualifies for usage-driven status), where warranted by the circumstances and so long as the subzone remains subject to the activation limit (
                            <E T="03">see</E>
                             § 400.2(b)) for the zone in question.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Applications for other revisions to authority.</E>
                             Applications or requests for other revisions to authority, such as for Board action to establish or modify an activation limit for a zone, modification of a restriction, reissuance of a grant of authority or request for a voluntary termination shall be submitted in letter form with information and documentation necessary for analysis, as determined by the Executive Secretary. If the change involves the removal or significant modification of a restriction included by the Board in its approval of authority or the reissuance of a grant of authority, the review procedures of §§ 400.31 through 400.34 and 400.36 shall be followed, where relevant. If not, the procedure set forth in § 400.38 shall generally apply (although the Executive Secretary may elect to follow the procedures of §§ 400.31 through 400.34 and 400.36 when warranted).
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>10. In § 400.26:</AMDPAR>
                    <AMDPAR>a. Revise the section heading;</AMDPAR>
                    <AMDPAR>b. In paragraph (d), add the word “and” following the semicolon;</AMDPAR>
                    <AMDPAR>c. In paragraph (e), remove “; and” and add a period in its place; and</AMDPAR>
                    <AMDPAR>d. Remove paragraph (f).</AMDPAR>
                    <P>The revision reads as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.26 </SECTNO>
                        <SUBJECT>Criteria for evaluation of proposals, including for zones, expansions, subzones, or other modifications of zones.</SUBJECT>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>11. In § 400.27, revise the introductory text to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.27 </SECTNO>
                        <SUBJECT>Criteria applicable to evaluation of applications for production authority.</SUBJECT>
                        <P>The Board shall apply the criteria set forth in this section in determining whether to approve an application for authority to conduct production activity pursuant to § 400.23. The Board's evaluation shall take into account information such as pertains to market conditions, price sensitivity, degree and nature of foreign competition, intra-industry and intra-firm trade, effect on exports and imports, ability to conduct the proposed activity outside the United States with the same U.S. tariff impact, analyses conducted in connection with prior Board actions, and net effect on U.S. employment and the U.S. economy:</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>12. In § 400.29:</AMDPAR>
                    <AMDPAR>a. Revise paragraphs (b) and (c); and</AMDPAR>
                    <AMDPAR>b. Remove paragraph (d).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.29 </SECTNO>
                        <SUBJECT>Application fees.</SUBJECT>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Uniform system of user fee charges.</E>
                             The following fee schedule establishes fees for certain types of applications and requests for authority on the basis of their estimated average processing time.
                        </P>
                        <P>(1) Additional zones (§ 400.21; § 400.11(a)(2))—$3,200.</P>
                        <P>(2) Subzones (§ 400.25):</P>
                        <P>(i) Not involving production activity or involving production activity with fewer than three products—$4,000.</P>
                        <P>(ii) Production activity with three or more products—$6,500.</P>
                        <P>(3) Expansions (§ 400.24(b))—$1,600.</P>
                        <P>
                            (c) 
                            <E T="03">Timing and manner of payment.</E>
                             Application fees shall be paid prior to the FTZ Board docketing an application and in a manner specified by the Executive Secretary.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>13. In § 400.31, revise paragraph (b) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.31 </SECTNO>
                        <SUBJECT>General application provisions and pre-docketing review.</SUBJECT>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Pre-docketing review.</E>
                             The applicant shall submit a complete copy 
                            <PRTPAGE P="8529"/>
                            of an application for pre-docketing review. The Executive Secretary shall determine whether the application satisfies the requirements of §§ 400.12, 400.21, and 400.23 through 400.25 and other applicable provisions of this part such that the application is sufficient for docketing. The applicant shall be notified within 30 days whether the pre-docketing copy of the application is sufficient. If the application is not sufficient, the applicant will be notified of the specific deficiencies. An affected zone participant may also be contacted regarding relevant application elements requiring additional information or clarification. If the applicant does not correct the deficiencies and submit a corrected pre-docketing application copy within 30 days of notification, the pre-docketing application shall be discarded. For applications subject to § 400.29, the fees shall be paid in accordance with § 400.29 once the application is determined to be sufficient.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>14. Revise § 400.32 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.32 </SECTNO>
                        <SUBJECT>Procedures for docketing applications and commencement of case review.</SUBJECT>
                        <P>(a) Once the pre-docketing copy of the application is determined to be sufficient and any fees under § 400.29 have been paid, the Executive Secretary shall within 15 days:</P>
                        <P>(1) Formally docket the application, thereby initiating the proceeding or review;</P>
                        <P>(2) Assign a case-docket number; and</P>
                        <P>(3) Notify the applicant of the formal docketing action.</P>
                        <P>(b) After initiating a proceeding based on an application under §§ 400.21 and 400.23 through 400.25, the Executive Secretary shall:</P>
                        <P>(1) Designate an examiner to conduct a review and prepare a report or memorandum with recommendations for the Board;</P>
                        <P>
                            (2) Publish in the 
                            <E T="04">Federal Register</E>
                             a notice of the formal docketing of the application and initiation of the review. The notice shall include the name of the applicant, a description of the proposal, and an invitation for public comment. If the application requests authority for production activity and indicates that a component to be used in the activity is subject to a trade-related measure or proceeding (
                            <E T="03">e.g.,</E>
                             AD/CVD order or proceeding, suspension of liquidation under AD/CVD procedures), the notice shall include that information. For applications to establish or expand a zone or for production authority, the comment period shall normally close 60 days after the date the notice appears. For applications for subzone designation, the comment period shall normally close 40 days after the date the notice appears. However, if a hearing is held (
                            <E T="03">see</E>
                             § 400.52), the comment period shall not close prior to 15 days after the date of the hearing. The closing date for general comments shall ordinarily be followed by an additional 15-day period for rebuttal comments. Requests for extensions of a comment period will be considered, subject to the standards of § 400.28(c). Submissions must meet the requirements of § 400.28(b). With the exception of submissions by the applicant, any new evidence or new factual information and any written arguments submitted after the deadlines for comments shall not be considered by the examiner or the Board. Submission by the applicant of new evidence or new factual information may result in the (re)opening of a comment period. A comment period may otherwise be opened or reopened for cause;
                        </P>
                        <P>(3) Transmit or otherwise make available copies of the docketing notice and the application to CBP;</P>
                        <P>(4) Arrange for hearings, as appropriate;</P>
                        <P>(5) Transmit the report and recommendations of the examiner and any comments by CBP to the Board for appropriate action; and</P>
                        <P>
                            (6) Notify the applicant in writing (via electronic means, where appropriate) and publish notice in the 
                            <E T="04">Federal Register</E>
                             of the Board's determination.
                        </P>
                        <P>(c) Any comments by CBP pertaining to the application shall be submitted to the Executive Secretary by the conclusion of the public comment period described in paragraph (b)(2) of this section.</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>15. In § 400.33, revise paragraph (e)(3) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.33 </SECTNO>
                        <SUBJECT>Examiner's review—application to establish or modify a zone.</SUBJECT>
                        <STARS/>
                        <P>(e) * * *</P>
                        <P>(3) If the factors considered for an examiner's recommendation(s) change as a result of new evidence, the applicable procedures of paragraphs (e)(1) and (2) of this section shall be followed.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>16. In § 400.34, revise paragraph (a)(5)(iv)(C) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.34 </SECTNO>
                        <SUBJECT>Examiner's review—application for production authority.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(5) * * *</P>
                        <P>(iv) * * *</P>
                        <P>(C) If the factors considered for an examiner's recommendation(s) change as a result of new evidence, the applicable procedures of paragraphs (a)(5)(iv)(A) and (B) of this section shall be followed.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>17. In § 400.35, revise paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.35 </SECTNO>
                        <SUBJECT>Examiner's review—application for subzone designation.</SUBJECT>
                        <STARS/>
                        <P>(c) If the factors considered for an examiner's recommendation(s) change as a result of new evidence, the applicable procedures of paragraphs (a) and (b) of this section shall be followed.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>18. In § 400.36:</AMDPAR>
                    <AMDPAR>a. Revise paragraphs (b) and (e); and</AMDPAR>
                    <AMDPAR>b. Remove the paragraph heading from paragraph (f).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.36 </SECTNO>
                        <SUBJECT>Completion of case review.</SUBJECT>
                        <STARS/>
                        <P>(b) In its advisory role to the Board, CBP headquarters staff shall provide any comments within 15 days for applications under § 400.25 and within 30 days for all other applications.</P>
                        <STARS/>
                        <P>(e) If the Board is unable to reach a unanimous decision, the applicant shall be notified and provided an opportunity to meet with the Board members or their delegates.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>19. In § 400.37, revise paragraph (a) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.37 </SECTNO>
                        <SUBJECT>Procedure for notification of proposed production activity.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Submission of notification.</E>
                             A notification for production authority pursuant to §§ 400.14(a) and 400.22 shall be submitted simultaneously to the Board's Executive Secretary and to CBP.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>20. Revise § 400.38 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.38 </SECTNO>
                        <SUBJECT>Procedure for request for minor modification of zone.</SUBJECT>
                        <P>
                            (a) The Executive Secretary shall make a determination in cases under § 400.24(c) involving minor modifications of zones that do not require Board action, such as boundary modifications, including certain relocations, and shall notify the requestor in writing of the decision on the request within 30 days of the Executive Secretary's receipt of the complete request and the CBP comments under paragraph (b) of this section. Depending on the specific request, the decision could be that the request cannot be processed under § 400.24(c). The requestor shall submit a copy of its request to CBP no later than the time of the requestor's submission of the request to the Executive Secretary.
                            <PRTPAGE P="8530"/>
                        </P>
                        <P>(b) If not previously provided to the requestor for inclusion with the requestor's submission of the request to the Executive Secretary, any CBP comments on the request shall be provided to the Executive Secretary within 20 days of the requestor's submission of the request to the Executive Secretary.</P>
                    </SECTION>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 400.42 </SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>21. In § 400.42, remove and reserve paragraph (b).</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 400.43 </SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>22. In § 400.43, remove paragraph (i).</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>23. In § 400.44:</AMDPAR>
                    <AMDPAR>a. Revise paragraphs (a), (b)(5), and (e); and</AMDPAR>
                    <AMDPAR>b. Remove paragraph (f).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 400.44 </SECTNO>
                        <SUBJECT>Zone schedule.</SUBJECT>
                        <P>(a) The zone grantee shall submit to the Executive Secretary (electronic copy or as specified by the Executive Secretary) a zone schedule which sets forth the elements required in this section. No element of a zone schedule (including any amendment to the zone schedule) may be considered to be in effect until such submission has occurred. If warranted, the Board may subsequently amend the requirements of this section by Board Order.</P>
                        <P>(b) * * *</P>
                        <P>(5) Information identifying any operator which offers services to the public and which has requested that its information be included in the zone schedule; and</P>
                        <STARS/>
                        <P>(e) A complete copy of the zone schedule shall be freely available for public inspection at the offices of the zone grantee. The Board shall make copies of zone schedules available on its website.</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>24. In § 400.45, revise paragraph (b) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.45 </SECTNO>
                        <SUBJECT>Complaints related to public utility and uniform treatment.</SUBJECT>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Objections to rates and charges.</E>
                             A zone participant showing good cause may object to any rate or charge related to the zone on the basis that it is not fair and reasonable by submitting to the Executive Secretary a complaint in writing with supporting information. If necessary, such a complaint may be made on a confidential basis pursuant to paragraph (a) of this section. The Executive Secretary shall review the complaint and issue a report and decision, which shall be final unless appealed to the Board within 30 days. The Board or the Executive Secretary may otherwise initiate a review for cause. The primary factor considered in reviewing fairness and reasonableness is the cost of the specific services rendered. Where those costs incorporate charges to the grantee by one or more parties undertaking functions on behalf of the grantee, the Board may consider the costs incurred by those parties or evidence regarding market rates for the undertaking of those functions. The Board may rely on best estimates, as necessary. The Board will also give consideration to any extra costs incurred relative to non-zone operations, including return on investment and reasonable out-of-pocket expenses.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>25. In § 400.52, revise paragraph (b)(2) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.52 </SECTNO>
                        <SUBJECT>Notices and hearings.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>
                            (2) The request must be made within 30 days of the beginning of the initial period for public comment (
                            <E T="03">see</E>
                             § 400.32) and must be accompanied by information establishing the need for the hearing and the basis for the requesting party's interest in the matter.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="15" PART="400">
                    <AMDPAR>26. In § 400.61, revise paragraphs (a) and (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 400.61 </SECTNO>
                        <SUBJECT>Revocation of authority.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">In general.</E>
                             As provided in this section, the Board can revoke in whole or in part authority for a zone (
                            <E T="03">see</E>
                             § 400.2(h)) whenever it determines that the zone grantee has violated, repeatedly and willfully, the provisions of the Act.
                        </P>
                        <STARS/>
                        <P>
                            (c) 
                            <E T="03">Appeals.</E>
                             As provided in section 18 of the Act (19 U.S.C. 81r(c)), the grantee of the zone in question may appeal an order of the Board revoking authority.
                        </P>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-01953 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL TRADE COMMISSION</AGENCY>
                <CFR>16 CFR Part 1</CFR>
                <RIN>RIN 3084-AB79</RIN>
                <SUBJECT>Procedures for Oversight of the Horseracing Integrity and Safety Authority's Annual Budget</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Trade Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Federal Trade Commission (“FTC” or “Commission”) is amending its rules pursuant to the Horseracing Integrity and Safety Act (“Act”) regarding the Commission's procedures for its oversight of the annual budget of the Horseracing Integrity and Safety Authority (“Authority”). The amendments to the Authority's budget oversight rules will streamline and improve the process for approving or disapproving the Authority's annual budget.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective on February 8, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sarah Botha, Attorney ((202-326-2036), 
                        <E T="03">sbotha@ftc.gov</E>
                        ), Office of the Executive Director, Federal Trade Commission.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    The Horseracing Integrity and Safety Act of 2020, Public Law 116-260, Title XII, 134 Stat 1182, 3252 (2020) (codified as amended at 15 U.S.C. 3051-3060), recognizes the Authority as a self-regulatory nonprofit organization charged with developing and enforcing rules relating to racetrack safety, anti-doping, and medication control. 
                    <E T="03">See</E>
                     15 U.S.C. 3052. The Act expressly provides for Commission oversight of several aspects of the Authority's operations. For example, the Commission must approve any proposed rule or rule modification by the Authority relating to the Authority's bylaws, racetrack safety standards, anti-doping and medication control, and the formula or methodology for determining assessments. 
                    <E T="03">See id.</E>
                     In December 2022, Congress amended HISA to expand the Commission's oversight role over the Authority. 
                    <E T="03">See</E>
                     Consolidated Appropriations Act, 2023, Public Law 117-328, Sec. 701, 136 Stat. 4459, 5231 (2022). As amended, the Act gives the Commission the power to issue rules under the procedures set forth in the Administrative Procedure Act, 5 U.S.C. 553, “as the Commission finds necessary or appropriate to ensure the fair administration of the Authority . . . or otherwise in furtherance of the purposes of this Act.” 15 U.S.C. 3053(e).
                </P>
                <P>
                    In March 2023, relying in part on the new amendment, the Commission promulgated rules relating to the Authority's budget (“Budget Rule”). 
                    <E T="03">See</E>
                     88 FR 18034 (Mar. 27, 2023). The Budget Rule, codified at 16 CFR 1.150 through 1.152, sets forth the process whereby the Authority submits each year's proposed budget to the Commission for approval. Under the Budget Rule, after the Authority submits its proposed annual budget to the Commission, the Commission publishes the proposed budget in the 
                    <E T="04">Federal Register</E>
                     and the public is given an opportunity to comment. 
                    <E T="03">See</E>
                     16 CFR 
                    <PRTPAGE P="8531"/>
                    1.150(d). After the close of the comment period, and after consideration of any comments received, the Commission either approves or disapproves the proposed budget, using the criteria set forth in 16 CFR 1.151(c).
                </P>
                <P>
                    In June 2023, after the Commission promulgated the Budget Rule, the Authority submitted its proposed 2023 budget to the Commission, and the Commission published the proposed budget in the 
                    <E T="04">Federal Register</E>
                    . 
                    <E T="03">See</E>
                     88 FR 68610 (Oct. 4, 2023). After considering the Authority's budget submission and the public comments received, the Commission approved the Authority's 2023 budget on December 5, 2023.
                    <SU>1</SU>
                    <FTREF/>
                     In September 2023, the Authority submitted its proposed 2024 budget to the Commission, and the Commission published the proposed budget in the 
                    <E T="04">Federal Register</E>
                    . 
                    <E T="03">See</E>
                     88 FR 77582 (Nov. 13, 2023). The Commission reviewed the Authority's budget submission and the public comments and approved the Authority's 2024 budget on January 5, 2024.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         FTC, Order Approving the Budget for 2023 Proposed by the Horseracing Integrity and Safety Authority (Dec. 5, 2023), 
                        <E T="03">available at https://www.ftc.gov/system/files/ftc_gov/pdf/P222100CommissionOrderApprovingHISA2023Budget.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         FTC, Order Approving the Budget for 2024 Proposed by the Horseracing Integrity and Safety Authority (Jan. 5, 2024), 
                        <E T="03">available at https://www.ftc.gov/system/files/ftc_gov/pdf/P222100CommissionOrder2024HISABudget.pdf.</E>
                    </P>
                </FTNT>
                <P>
                    Based on comments received in response to the publication of the 2023 and 2024 budgets, and in light of Commission experience in reviewing the two budgets, the Commission is revising the Budget Rule, 16 CFR 1.150 through 1.152. The revisions to the Rule streamline the budget approval process by, among other things, providing for the immediate publication of the Authority's proposed budget in the 
                    <E T="04">Federal Register</E>
                     so long as certain procedural requirements are met. The amendments to the budget approval process still allow for meaningful public comment, and the Commission will still need to closely review the Authority's finances. Commission approval of the budget will happen only after the Commission is satisfied that the budget is consistent with and serves the goals of the Act in a prudent and cost-effective manner.
                </P>
                <P>Finally, the Commission is modifying § 1.143, the section setting forth the formatting requirements for the Authority's submissions to the Commission, to account for the submissions mandated by §§ 1.150 through 1.152.</P>
                <HD SOURCE="HD1">Section by Section Analysis</HD>
                <P>
                    <E T="03">§ 1.143 Submissions to the Secretary.</E>
                     Section 1.143 currently sets forth the procedures whereby the Authority submits guidance, proposed rate increases, and proposed rules or rule modifications to the Commission. The Commission is modifying this section to account for the Authority's submissions required by the Budget Rule.
                </P>
                <P>
                    <E T="03">§ 1.150 Submission of the Authority's proposed budget.</E>
                     Modifications to paragraph (a) change the budget submission date from September 1 to August 1 to give the FTC additional time to review the Authority's proposed budget. Changes to paragraph (b) clarify that the Authority does not have to post public comments to its website upon their arrival, but must still post comments on its website. Also, the Commission is moving from paragraph (b) to paragraph (c) the requirement that the Authority forward to the FTC any public comments received by the Authority and the Authority's response to them. The changes to paragraph (d) delegate to the Secretary the authority to publish the proposed budget in the 
                    <E T="04">Federal Register</E>
                     without a Commission vote. The Commission will still vote to approve or disapprove the budget after the public comment period has ended and the Commission has reviewed the comments submitted. The Commission also clarifies that while the proposed budget will still be published in the 
                    <E T="04">Federal Register</E>
                    , supporting materials will be made available to the public on 
                    <E T="03">regulations.gov.</E>
                </P>
                <P>
                    <E T="03">§ 1.151 Commission's decision on the Authority's proposed budget.</E>
                     Modifications to this section clarify that the Commission may require the Authority to submit additional information before the Commission approves or disapproves the proposed budget, and that the Commission will vote on the Authority's proposed budget no later than November 1, or as soon as practicable thereafter. Changes also remove the “commercially reasonable terms” element from the Commission's decision criteria. In lieu of this criterion, the FTC today proposes new provisions addressing oversight of the Authority's operations, which would include more specific vendor selection and competition requirements.
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Horseracing Integrity and Safety Authority Oversight, Notice of Proposed Rulemaking, published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                </FTNT>
                <P>
                    <E T="03">§ 1.152 Deviation from approved budget.</E>
                     An edit in paragraph (a) clarifies that the Authority may deviate from the approved budget's expenditure information in a year as to any line item by up to 10 percent in a year without notifying the Commission. Edits in paragraphs (b) and (c) change the deadlines from 7 business days to 14 business days for the Commission to issue any decision to disapprove a proposed repurposing of funds to cover a line-item deviation of more than 10 percent and for the Commission to issue any decision to disapprove a proposed means of covering a difference in the total approved expenditure.
                </P>
                <P>
                    Because these rules relate solely to agency procedure and practice, publication for notice and comment is not required under the Administrative Procedure Act. 5 U.S.C. 553(b).
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         For this reason, the requirements of the Regulatory Flexibility Act, 5 U.S.C. 601(2), 604(a), are also inapplicable. Likewise, the amendments do not modify any FTC collections of information within the meaning of the Paperwork Reduction Act, 44 U.S.C. 3501 through 3521.
                    </P>
                </FTNT>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 16 CFR Part 1</HD>
                    <P>Administrative practice and procedure; Animal drugs; Animal welfare. </P>
                </LSTSUB>
                <P>For the reasons set forth in the preamble, the Federal Trade Commission amends part 1, title 16, chapter I, subchapter A of the Code of Federal Regulations as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 1—GENERAL PROCEDURES</HD>
                </PART>
                <REGTEXT TITLE="16" PART="1">
                    <AMDPAR>1. The authority citation for part 1 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>15 U.S.C. 46; 15 U.S.C. 57a; 5 U.S.C. 552; 5 U.S.C. 601 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="16" PART="1">
                    <AMDPAR>2. Amend § 1.143 by revising paragraph (a), paragraph (b) paragraph heading, (b)(1), (e), and (f) of to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1.143 </SECTNO>
                        <SUBJECT>Submissions to the Secretary.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Electronic submission.</E>
                             All submissions from the Authority to the Commission pursuant to the provisions of subpart S or U of this part, and all submissions to the Commission pursuant to 15 U.S.C. 3053(a) (proposed rules or rule modifications), 15 U.S.C. 3052(f)(1)(C)(iv) (proposed rate increases), or 15 U.S.C. 3054(g)(2) (guidance) must be emailed to the Secretary of the Commission at 
                            <E T="03">electronicfilings@ftc.gov.</E>
                             The subject line of the email must begin with “HISA Submission:” followed by a brief description of the submission.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Format for submissions—</E>
                            (1) 
                            <E T="03">Electronic format.</E>
                             All documents submitted to the Secretary under this section must be submitted in .pdf format or in some other electronic format specified by the Office of the Secretary. 
                            <PRTPAGE P="8532"/>
                            The proposed text of 
                            <E T="04">Federal Register</E>
                             publications must also be submitted in a Microsoft Word or .rtf format.
                        </P>
                        <STARS/>
                        <P>
                            (e) 
                            <E T="03">Authority to reject documents for filing.</E>
                             The Secretary of the Commission may reject a document for filing that fails to comply with the Commission's rules.
                        </P>
                        <P>
                            (f) 
                            <E T="04">Federal Register</E>
                              
                            <E T="03">publication.</E>
                             For submissions required to be published in the 
                            <E T="04">Federal Register</E>
                            , if the conditions set forth in this section and § 1.142 have been satisfied, the Commission will publish the Authority's submission in the 
                            <E T="04">Federal Register</E>
                            .
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="16" PART="1">
                    <AMDPAR>3. Revise subpart U to read as follows:</AMDPAR>
                    <SUBPART>
                        <HD SOURCE="HED">Subpart U—Procedures for Oversight of the Horseracing Integrity and Safety Authority's Annual Budget</HD>
                    </SUBPART>
                    <CONTENTS>
                        <SECHD>Sec.</SECHD>
                        <SECTNO>1.150 </SECTNO>
                        <SUBJECT>Submission of the Authority's proposed budget</SUBJECT>
                        <SECTNO>1.151 </SECTNO>
                        <SUBJECT>Commission decision on the Authority's proposed budget</SUBJECT>
                        <SECTNO>1.152 </SECTNO>
                        <SUBJECT>Deviation from approved budget</SUBJECT>
                    </CONTENTS>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>15 U.S.C. 3053(e).</P>
                    </AUTH>
                    <SECTION>
                        <SECTNO>§ 1.150 </SECTNO>
                        <SUBJECT>Submission of the Authority's proposed budget submissions.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Mandatory annual submission.</E>
                             The Authority must submit a proposed annual budget to the Commission every year, irrespective of whether there is a “proposed increase in the amount required” under 15 U.S.C. 3052(f)(1)(C)(iv). The submission of the proposed budget for the following year must be made by August 1 of the current year, following the procedures set forth in § 1.143. The Authority's annual budget will use the calendar year as its fiscal year.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Consideration of public comments.</E>
                             Before submitting its proposed budget to the Commission in August, the Authority must post the proposed budget on its website as early as practicable, with an invitation to the public to submit comments to the Authority on any aspect of the proposed budget. The Authority must post any pertinent comments it receives on its website, and it must review them to ascertain whether to revise the proposed budget in light of them.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Contents of submission.</E>
                             The Authority's proposed budget submission to the Commission must include the following:
                        </P>
                        <P>
                            (1) 
                            <E T="03">Indication of Board vote.</E>
                             The Authority's proposed budget must be approved by a majority of its Board of Directors, or, in the case of a budget that exceeds the preceding year's budget by 5 percent or more, a two-thirds supermajority. The Authority's submission to the Commission must state the Board vote on the motion to approve the budget.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Revenue information.</E>
                             The proposed budget must identify both the estimated amount required from each State racing commission as calculated under 15 U.S.C. 3052(f) and all other sources of Authority revenue as well as any loans proposed to be obtained by the Authority.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Expenditure information.</E>
                             The proposed budget must identify expenditures separately for:
                        </P>
                        <P>(i) The racetrack safety program;</P>
                        <P>(ii) The anti-doping and medication control program;</P>
                        <P>(iii) All other programmatic expenditures other than for racetrack safety and anti-doping and medication control, such as the administration of the Authority or its technological needs;</P>
                        <P>(iv) Repayment of any loans; and</P>
                        <P>(v) Any funding shortfall incurred.</P>
                        <P>
                            (4) 
                            <E T="03">Line items.</E>
                             For both revenue and expenditure information, the Authority's proposed budget must provide sufficient information, by line item, as would be required for members of the Authority's Board of Directors to exercise their fiduciary duty of care. For example, the proposed budget's expenditure information for anti-doping and medication control might include separate line items for in-house salaries, the costs of testing of laboratory samples, the costs of arbitrators, and all the costs associated with contracting with an anti-doping and medication control enforcement agency. The proposed budget must include a narrative component that provides a brief explanation of each line item's utility in carrying out the purposes of the Horseracing Integrity and Safety Act.
                        </P>
                        <P>
                            (5) 
                            <E T="03">Comparison of approved budget to actual revenues and expenditures.</E>
                             For each approved line item, the proposed budget must provide a comparison showing the actual revenues and expenditures for the current year along with a narrative component explaining why any line item is anticipated to deviate by 10 percent or more during the current year.
                        </P>
                        <P>
                            (6) 
                            <E T="03">Public comments received and the Authority's response.</E>
                             The Authority must include with its submission all of the public comments that it received after posting the proposed budget on its website. The Authority must also provide an assessment of public comments relevant to the Commission's evaluation of the proposed budget. The Authority must also identify any changes made to the proposed budget in response to the comments received.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Publication of the proposed budget in the</E>
                              
                            <E T="04">Federal Register</E>
                            . If the Secretary concludes that the Authority's submission complies with § 1.150(c), then the Secretary will publish the Authority's proposed budget in the 
                            <E T="04">Federal Register</E>
                             with supporting materials available on 
                            <E T="03">regulations.gov.</E>
                             Members of the public will have 14 days after the date of publication in which to file comments on the proposed budget. Public comments should provide commenters' views as to the decisional criteria set forth in § 1.151(c) and whether any line items should be modified.
                        </P>
                    </SECTION>
                    <SECTION>
                        <SECTNO>§ 1.151 </SECTNO>
                        <SUBJECT>Commission decision on the Authority's proposed budget.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Commission approval required.</E>
                             The Authority's proposed budget takes effect only if approved by the Commission. The Commission will approve or disapprove the proposed budget after considering the public comments filed and the Commission's internal review of the Authority's submissions pursuant to § 1.150. The Commission may, in its discretion, require the Authority to submit additional information to the Commission before the Commission approves or disapproves the proposed budget. The Commission will vote on the Authority's proposed budget no later than November 1, or as soon thereafter as practicable.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Conditional collection of fees allowed.</E>
                             The notice required to be sent to State racing commissions estimating the amount required from each State for the subsequent year must state that the amount required is based on the proposed annual budget, as approved by the Board of Directors, which takes effect only if approved by the Commission. State racing commissions (or covered persons in States that do not elect to remit fees) may nevertheless elect to remit fees, and the Authority may conditionally collect them, even before the Commission approves the proposed budget. If the Commission makes any modifications to line items under paragraph (d) of this section that have the net effect of reducing the budget, the Authority must, within 30 days, refund the proportionate amount owed to any State racing commission or covered person that has conditionally paid. If the Commission makes any modifications to line items under paragraph (d) of this section that have the net effect of increasing the budget, the Authority may obtain loans to make up the difference or may account for the difference as a funding shortfall incurred in the subsequent year's proposed budget.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Decisional criteria.</E>
                             The Commission will approve the proposed 
                            <PRTPAGE P="8533"/>
                            budget if the Commission determines that, on balance, the proposed budget is consistent with and serves the goals of the Horseracing Integrity and Safety Act in a prudent and cost-effective manner and that its anticipated revenues are sufficient to meet its anticipated expenditures.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Modification of line items.</E>
                             In its decision on the proposed budget, the Commission may modify the amount of any line item.
                        </P>
                    </SECTION>
                    <SECTION>
                        <SECTNO>§ 1.152 </SECTNO>
                        <SUBJECT>Deviation from approved budget.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">When notice to the Commission is required.</E>
                             As to any line item, the Authority may deviate from the approved budget's expenditure information in a year by up to 10 percent in a year without providing prior notification to the Commission. If the Authority determines that it is likely to expend more than the approved expenditure for any line item by 10 percent or more, or if it will exceed its approved total expenditure by any amount, it must notify the Commission immediately upon such a determination.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Line-item deviations of more than 10 percent.</E>
                             If the Authority determines that it is likely to expend more than the approved expenditure for any line item by 10 percent or more, its notice to the Commission must indicate whether it intends to repurpose funds from one or more different line items to cover the increased expenditure. The Commission retains the discretion to disapprove such a proposed repurposing. The Commission must issue any decision to disapprove a proposed repurposing within 14 business days of receiving notice of the Authority's proposal to repurpose funds from another line item. If the Commission takes no action, the Authority's proposal takes effect as an amendment to its approved budget.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Total expenditure deviation.</E>
                             If the Authority determines that it is likely to expend more than the total approved expenditure, its notice to the Commission must indicate by what means it proposes to cover the difference. The Commission retains the discretion to disapprove the proposed means of covering the difference. The Commission must issue any decision to disapprove a proposed means of covering the difference within 14 business days of receiving notice of the Authority's proposal to cover the difference. If the Commission takes no action, the Authority's proposal takes effect as an amendment to its approved budget.
                        </P>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <P>By direction of the Commission,</P>
                    <NAME>Joel Christie,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02290 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6750-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF LABOR</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <CFR>20 CFR Part 802</CFR>
                <RIN>RIN 1290-AA35</RIN>
                <SUBJECT>Rules of Practice and Procedure Before the Benefits Review Board</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Secretary, Department of Labor.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This action finalizes the Department of Labor's (DOL or Department) proposal, published on January 11, 2021, to require electronic filing (e-filing) in proceedings before the Benefits Review Board (BRB). On January 11, 2021, the Department published a direct final rule (DFR) and companion proposed rule to require e-filing and make acceptance of electronic service (e-service) automatic by attorneys and lay representatives representing parties in proceedings before the BRB, and to provide an option for self-represented parties to utilize these electronic capabilities. The rule provided an exception to the requirements for good cause shown. The Department invited written comments from the public for 30 days on the proposed rule. The Department received significant adverse public comments from stakeholders on the similar direct final rule for the Office of Administrative Law Judges (OALJ). As many of these stakeholders also practice before the BRB, the BRB withdrew the direct final rule on February 25, 2021. The Department has reviewed the comments received in response to the proposal and is now implementing the rule as described in the proposed rule of January 11, 2021, with appropriate exceptions for good cause shown and self-represented parties.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective on March 11, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Mr. Thomas Shepherd, Clerk of the Appellate Boards, at 202-693-6319.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This preamble is divided into three sections: Section I provides an overview of this rulemaking and describes its procedural background; Section II provides a summary of the public comments received; and Section III covers the administrative requirements for this rulemaking.</P>
                <HD SOURCE="HD1">I. Background</HD>
                <HD SOURCE="HD2">A. Overview</HD>
                <P>
                    This action is a final rule to finalize the corresponding notice of proposed rulemaking (NPRM) published in the January 11, 2021, issue of the 
                    <E T="04">Federal Register</E>
                    . The e-filing amendments are revising Part 802 in order to require e-filing and allow for automatic e-service.
                </P>
                <P>
                    A general overview of the legal framework, statements explaining the necessity of this e-filing and e-service rule, and further background on the rulemaking is available in the Department's NPRM, as published in the 
                    <E T="04">Federal Register</E>
                     on January 11, 2021, and will not be restated in full herein.
                </P>
                <P>In brief, this final rule requires persons represented by attorney and non-attorney representatives to use the Department's system to file all papers electronically and to receive electronic service of documents unless another form of filing or service is allowed by the BRB for good cause; gives self-represented persons the option to use conventional means of filing, or to use the Department's system to file all papers electronically and to receive electronic service of documents; and provides that a filing made through a person's eFile/eServe system account and authorized by that person, together with that person's name on a signature block, constitutes that person's signature.</P>
                <HD SOURCE="HD2">B. Procedural History</HD>
                <P>
                    On January 11, 2021, the Department initially published the e-filing amendments as a DFR without a prior proposal because the Department viewed such amendments as noncontroversial at that time and anticipated no adverse comment. The Department also published a companion NPRM in the “Proposed Rules” section of the January 11, 2021, issue to expedite notice-and-comment rulemaking in case significant adverse comments were received from stakeholders. A significant adverse comment for the purposes of these notices is one that explains (1) why the rule is inappropriate, including challenges to the rule's underlying premise or approach; or (2) why the direct final rule will be ineffective or unacceptable without a change. The proposed and direct final rules were substantively identical, and their respective comment periods ran concurrently. The Department is treating comments received on the 
                    <PRTPAGE P="8534"/>
                    companion direct final rule as comments regarding the proposed rule, and vice versa.
                </P>
                <P>On January 11, 2021, OALJ also published e-filing amendments as a DFR, as well as a companion NPRM. Like the BRB rule, the OALJ rule would require e-filing for represented persons unless good cause is shown that justifies an alternative form of filing, and self-represented persons would have the option to e-file or file papers conventionally. The OALJ rule would deem any person required to e-file, or who opts to e-file, as having consented to e-service through the eFile/eServe system.</P>
                <P>On February 25, 2021, the Department withdrew the January 11, 2021, DFR due to the receipt of significant adverse comment on a similar rulemaking by the OALJ. Accordingly, on March 17, 2021, the Department re-opened the comment period on the January 11, 2021, NPRM for 15 days in order to give the public an additional opportunity to voice concerns regarding the proposed e-filing rule. The Department also scheduled listening sessions in order to better understand and address concerns from practitioners and the regulated community.</P>
                <HD SOURCE="HD1">II. Public Comments Received</HD>
                <P>
                    The Department invited written comment in its January 11, 2021, DFR and concurrently published NPRM. The proposed and direct final rules were substantively identical, and their comment periods ran concurrently from January 11, 2021, to February 10, 2021. On March 17, 2021, the NPRM comment period was reopened for fifteen days. Comments were submitted electronically at 
                    <E T="03">https://www.regulations.gov/</E>
                     using docket number DOL-2020-0013. The Department requested comments on all issues related to the rule, including economic or other regulatory impacts of the rule on the regulated community.
                </P>
                <P>
                    In issuing this final action, the Department considered comments received on the DFR and NPRM during both the initial and subsequent comment periods. The Department also considered comments received on the similar OALJ rulemaking because commenters noted that they also practiced before the BRB. Comments to the OALJ rulemaking were submitted electronically at 
                    <E T="03">https://www.regulations.gov/</E>
                     using docket number DOL-2020-0015.
                </P>
                <P>The Department received thirty-seven unique comments collectively on its BRB and OALJ e-filing rules. Of the thirty-seven comments received, twelve were determined to be out of scope because they were comments exclusively on the technical aspects of the Electronic Filing System and did not address the substance of the e-filing rule, addressed issues wholly unrelated to this rulemaking, or were general statements. Of the remaining twenty-five comments, one commenter—who commented on the BRB's NPRM—supported the e-filing rule and twenty-four raised concerns that are discussed below.</P>
                <HD SOURCE="HD2">A. Comment Supporting the E-Filing Rule</HD>
                <P>
                    The BRB received one comment in support of the rule's e-filing requirement and automation of e-service, and the rule's extension of the e-filing and e-service options to self-represented parties. The commenter attested to the “overall greater convenience for both parties to use e-filing and e-service, as well as the costs saved by going paperless.” They observed that “it is in the public interest for the DOL to create a streamlined procedure” because “[a] disarray of inconsistent filing methods is not only burdensome to those processing at DOL, but also to those who would like to track their submitted applications.” Additionally, the commenter cited to both 
                    <E T="03">Forbes</E>
                     and the New York City Bar Environmental Law Committee in addressing the range of significant environmental benefits that e-filing provides.
                </P>
                <P>This comment reflects the Department's belief that e-filing will benefit all participants in BRB matters. The greater utilization of e-filing and e-service will reduce case processing times by eliminating the timeframes required to allow for the delivery of traditional mailings. These time savings will allow the BRB to more efficiently process appeals without any sacrifice to the quality of work. It also will greatly reduce mailing and copying costs for both the BRB and the parties. The Department agrees that the cost, convenience, and efficiency benefits merit this final rule.</P>
                <HD SOURCE="HD2">B. Comments Raising Concerns About the E-Filing Rule</HD>
                <P>Nearly all commenters raising concerns about the rule identified themselves as practitioners before the BRB or OALJ. These commenters predominately objected to the rule's e-filing mandate, but many expressed support for the Department's efforts to move to e-filing and e-service. Three opposing commenters addressed concerns with other rule provisions.</P>
                <HD SOURCE="HD3">1. Comments Regarding the Portion of the Rule That Makes E-Filing Mandatory</HD>
                <P>Twenty-three commenters to the OALJ's NPRM recommended that the rule's e-filing mandate be delayed or abandoned. Several commenters expressed general support for the efficiency and modernization that e-filing provides. However, commenters expressed frustration with the BRB and OALJ e-filing systems, which they found to be time-consuming, resource intensive, and difficult to navigate. Accordingly, commenters asked that the e-filing mandate be abandoned or delayed to allow for the eFile/eServe system's redesign.</P>
                <P>Three of these commenters encouraged the continued use of paper filings to accommodate unreliable technology. One practitioner identified the particular technological barriers faced by black lung practitioners, who “likely have some of the worst internet service in the United States” and “[o]ften experience the loss of internet access.” Another noted, “[i]f internet service is disrupted, we currently have backup: `snail mail', wherein dropping a document in the mail constitutes proper service.” Practitioners also expressed concern that self-represented applicants may be disadvantaged if they cannot use the e-filing system successfully.</P>
                <P>The Department has acknowledged the commenters' concerns with the e-filing system and has sought to improve the system's user experience. All twenty-three comments requesting that the rule be delayed due to concerns about the eFile/eServe system were made on the OALJ's NPRM during the initial comment period that closed on February 10, 2021. After receiving these comments, the Department held listening sessions for users to provide feedback on the e-filing system. The Department relied on the information obtained at these listening sessions to improve the eFile/eServe system. The Department is confident it has sufficiently addressed the issues identified and that the e-filing mandate should therefore be implemented without additional delay.</P>
                <P>
                    Additionally, the final rule sufficiently responds to the commenters' technology concerns. First, Section 802.222(d)(2) allows attorneys and lay representatives to request an exemption from the e-filing mandate for good cause. Individuals who anticipate technological barriers to e-filing may use this provision to request an exemption. Second, Section 802.222(d)(3) allows self-represented parties to file in either electronic or 
                    <PRTPAGE P="8535"/>
                    nonelectronic format. Third, Section 802.222(d)(5) provides remedies for parties who experience technical failures in the e-filing, e-service process. Overall, the BRB framework is largely consistent with Federal district court and U.S. Courts of Appeals practice, which generally mandates e-filings for attorneys unless an exemption is granted and provides self-represented parties the option of filing pleadings in paper form.
                </P>
                <HD SOURCE="HD3">2. Comments Regarding Portions of the Rule Addressing Filing Deadlines, Public Access, and Service</HD>
                <P>
                    One commenter asked that the rule's computations of time be changed to allow e-filings to be considered timely if they are filed by 11:59 p.m. based on the time zone in which the filer is located. Section 802.221(c) requires that filing deadlines be computed using the Eastern Time zone. The Board chose the Eastern Time zone based on the fact that Washington, DC is located within it. This approach mirrors the approach of the Federal courts. 
                    <E T="03">See, e.g.,</E>
                     Fed. R. App. P. 26(a)(4); Fed. R. Civ. P.6(a)(4).
                </P>
                <P>The Department has considered this request and finds that maintaining the rulemaking's filing deadline computation better effectuates its goal of efficiently processing case appeals. Computing filing deadlines by the BRB's time zone allows the BRB to expeditiously determine whether a filing is timely. In contrast, a filing deadline based on the filer's location creates an administrative burden because it requires an individualized assessment of the filer's location, which may not be readily apparent in firms with multiple office locations.</P>
                <P>One commenter asserted that requiring separate e-service was inefficient and requested that the eFile/eServe system be changed to make service on all parties automatic. Section 802.223(b)(2)(B) allows for e-service to be completed by sending a filing to a user registered with the Department's eFile/eServe system. The eFile/eServe system is designed to function similarly to the Case Management/Electronic Case Files (CM/ECF) system used by the Federal courts. This approach allows for automatic e-service, with minimal exceptions for exempt individuals and documents containing sensitive information that must be served through an alternative, secure method. Accordingly, the Department has taken measures to establish automatic service through the eFile/eServe system.</P>
                <P>One commenter expressed concern that e-filing would impede public access to BRB and OALJ case files because the rule does not allow for general access by non-parties. The Department believes that public policy concerns merit the level of public access provided, which balances the public's right to know about proceedings and the parties' privacy interests. Here, broad public access is inappropriate because of the significant personal information contained within BRB and OALJ case files. Black lung and longshore claims also often contain extensive information of a private nature, where general public interest is limited.</P>
                <P>
                    Restricting general access by non-parties is consistent with the approach of the Federal courts in similar cases. Fed. R. Civ. P. 5.2(c) limits remote public access to electronic files in Social Security and immigration cases due to the significant amount of personal information these files contain. Rule 5.2(c) of the Federal Rules of Civil Procedure does not completely bar public access because it permits non-parties to obtain the full case file at the courthouse. Likewise, this rulemaking limits non-parties' remote access to electronic files, while allowing access through an alternative means. The Freedom of Information Act (FOIA) governs public access to agency rules, opinions, orders, records, and proceedings. 
                    <E T="03">See</E>
                     5 U.S.C. 552; 29 CFR 70.1 through 70.54. Under FOIA, non-parties may submit a request to obtain BRB and OALJ case files subject to the applicable FOIA exceptions. Accordingly, this final rule's restrictions on non-parties' access to electronic records in agency proceedings are consistent with FOIA's public access provisions, the Federal court process, and the policy considerations inherent in Fed. R. Civ. P. 5.2(c).
                </P>
                <HD SOURCE="HD2">C. Out of Scope Comments</HD>
                <P>Twelve comments, seven of which were made on the BRB's NPRM, were beyond the scope of this action. Five comments related only to specific concerns about using the Electronic Filing System, rather than the rule's specific e-filing mandate or other procedural amendments. To the extent that these comments refer to the e-filing mandate, these comments do not alter the Department's conclusion for the reasons noted above. One of these five comments was made on the BRB's NPRM. The commenter noted having difficulty finding an appeal in the eFile/eServe system because it failed to list cases by the claimant's first or last name, and instead listed cases by the BRB case number. In response to this comment, the Department has improved the system to allow a user to search for a case by a claimant's name, among other parameters. Another comment, also made on the BRB's NPRM, appears to pose questions to employers about their “coronavirus response plan,” and is therefore out of scope. Finally, six comments—five of which were made on the BRB's NPRM—made general and vague statements that did not address specific provisions of the proposed rules, or about e-filing or e-service, and were therefore also out of scope.</P>
                <HD SOURCE="HD2">D. Removal of Delayed Applicability Date</HD>
                <P>
                    This final rule will take effect 30 days after the date it is published in the 
                    <E T="04">Federal Register</E>
                    . Although this is a rule of agency procedure, the Department is using the minimum period provided under Section 553(d) of the APA for substantive rules that do not meet a statutory exception. 
                    <E T="03">See</E>
                     5 U.S.C. 553(d)(3). The Department is removing the 45-day delayed applicability date included in the initial DFR and NPRM. 
                    <E T="03">See Rules of Practice and Procedure for the Benefits Review Board,</E>
                     86 FR 1858, 1861, 1862 (proposed Jan. 11, 2021). The 30-day period between publication and the effective date of this final rule is reasonable and practical because the eFile/eServe system is currently operational. Accordingly, the Department no longer needs additional time to update communications about e-filing or to allow parties time to adjust to the e-filing system given the lengthy period since the public has been on notice of this proposed rule. The Department determines that both it and the public are prepared to adhere to the e-filing mandate within 30 days of this rule's publication, obviating the need for a delayed applicability date. Thus, the rule clarifies that attorneys and lay representatives must be registered with the BRB's eFile/eServe system—and file all pleadings, exhibits, and other documents through this system—by the effective date of the final rule.
                </P>
                <HD SOURCE="HD1">III. Administrative Requirements of the Rulemaking</HD>
                <HD SOURCE="HD2">Executive Orders 12866, Regulatory Planning and Review; and 13563, Improving Regulation and Regulatory Review</HD>
                <P>
                    Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 13563 emphasizes the importance of quantifying both costs and benefits, 
                    <PRTPAGE P="8536"/>
                    reducing costs, harmonizing rules, and promoting flexibility.
                </P>
                <P>This final rule has been drafted and reviewed in accordance with Executive Order 12866, as amended by Executive Order 14094. The Office of Information and Regulatory Affairs of the Office of Management and Budget (OMB) determined that this final rule is not a significant regulatory action under section 3(f) of Executive Order 12866 because the rule will not have an annual effect on the economy of $200 million or more; will not create a serious inconsistency or otherwise interfere with an action taken or planned by another agency; and will not materially alter the budgetary impact of entitlements, grants, user fees, or loan programs or the rights and obligations of recipients thereof. Furthermore, the rule does not raise legal or policy issues for which centralized review would meaningfully further the President's priorities, or the principles set forth in the Executive order. Accordingly, OMB has waived review.</P>
                <HD SOURCE="HD2">Regulatory Flexibility Act of 1980</HD>
                <P>
                    Because no notice of proposed rulemaking is required for this rule under section 553(b) of the Administrative Procedure Act, the regulatory flexibility requirements of the Regulatory Flexibility Act, 5 U.S.C. 601, do not apply to this rule. 
                    <E T="03">See</E>
                     5 U.S.C. 601(2).
                </P>
                <HD SOURCE="HD2">Paperwork Reduction Act</HD>
                <P>
                    The Department has determined that this final rule is not subject to the requirements of the Paperwork Reduction Act, 44 U.S.C. 3501 
                    <E T="03">et seq.,</E>
                     as this rulemaking involves administrative actions to which the Federal Government is a party or that occur after an administrative case file has been opened regarding a particular individual. 
                    <E T="03">See</E>
                     5 CFR 1320.4 (a)(2) and (c).
                </P>
                <HD SOURCE="HD2">Unfunded Mandates Reform Act of 1995 and Executive Order 13132, Federalism</HD>
                <P>
                    The Department has reviewed this rule in accordance with the requirements of Executive Order 13132 and the Unfunded Mandates Reform Act of 1995, 2 U.S.C. 1501 
                    <E T="03">et seq.,</E>
                     and has found no potential or substantial direct effects on the states, on the relationship between the national government and the states, or on the distribution of power and responsibilities among the various levels of government. As there is no Federal mandate contained herein that could result in increased expenditures by state, local, and Tribal Governments, or by the private sector, the Department has not prepared a budgetary impact statement.
                </P>
                <HD SOURCE="HD2">Executive Order 13175, Consultation and Coordination With Indian Tribal Governments</HD>
                <P>The Department has reviewed this rule in accordance with Executive Order 13175 and has determined that it does not have “tribal implications.” The direct final rule does not “have substantial direct effects on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.”</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 20 CFR Part 802</HD>
                    <P>Administrative practice and procedure, Black lung benefits, Longshore and harbor workers, Workers' compensation.</P>
                </LSTSUB>
                <P>For the reasons set forth in the preamble, the Department of Labor amends 20 CFR part 802 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 802—RULES OF PRACTICE AND PROCEDURE</HD>
                </PART>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>1. The authority citation for part 802 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                            5 U.S.C. 301; 30 U.S.C. 901 
                            <E T="03">et seq.;</E>
                             33 U.S.C. 901 
                            <E T="03">et seq.;</E>
                             Reorganization Plan No. 6 of 1950, 15 FR 3174; Secretary of Labor's Order 03-2006, 71 FR 4219, January 25, 2006.
                        </P>
                    </AUTH>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 802.204</SECTNO>
                    <SUBJECT> [Removed and Reserved]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>2. Remove and reserve § 802.204.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 802.207</SECTNO>
                    <SUBJECT> [Removed and Reserved]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>3. Remove and reserve § 802.207.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 802.216</SECTNO>
                    <SUBJECT> [Removed and Reserved]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>4. Remove and reserve § 802.216.</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>5. In § 802.219, revise paragraph (d) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 802.219</SECTNO>
                        <SUBJECT> Motions to the Board; orders.</SUBJECT>
                        <STARS/>
                        <P>(d) The rules governing the filing and service of documents in §§ 802.222 and 802.223 apply to all motions.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>6. Revise § 802.221 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 802.221</SECTNO>
                        <SUBJECT> Computation of time.</SUBJECT>
                        <P>(a) In computing any period of time prescribed or allowed by these rules, by direction of the Board, or by any applicable statute which does not provide otherwise, the day from which the designated period of time begins to run must not be included. The last day of the period so computed must be included, unless it is a Saturday, Sunday, or legal holiday, in which event the period runs until the end of the next day which is not a Saturday, Sunday, or legal holiday.</P>
                        <P>(b) For nonelectronic documents, the time period computed under paragraph (a) of this section will be deemed complied with if—</P>
                        <P>(1) When sent by mail, the envelope containing the document is postmarked by the U.S. Postal Service within the time period allowed. If there is no such postmark, or it is not legible, other evidence such as, but not limited to, certified mail receipts, certificates of service, and affidavits, may be used to establish the mailing date.</P>
                        <P>(2) When sent by commercial carrier, the receipt or tracking information demonstrates that the paper was delivered to the carrier within the time period allowed.</P>
                        <P>(c) For electronic filings made through the Board's case management system, paragraph (a) of this section will be deemed to be met if the document is electronically filed within the time period allowed. A document is deemed filed as of the date and time the Board's electronic case management system records its receipt, even if transmitted outside of the Board's business hours set forth in § 801.304 of this chapter. To be considered timely, an e-filed pleading must be filed by 11:59:59 p.m. Eastern Time on the due date.</P>
                        <P>(d) A waiver of the time limitations for filing a paper, other than a notice of appeal, may be requested by proper motion filed in accordance with §§ 802.217 and 802.219.</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>7. Add § 802.222 to subpart B to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 802.222</SECTNO>
                        <SUBJECT> Filing notice of appeal, pleadings, and other correspondence.</SUBJECT>
                        <P>This section prescribes rules and procedures by which parties and representatives to proceedings before the Board file pleadings (including notices of appeal, petitions for review and briefs, response briefs, additional briefs, and motions), exhibits, and other documents including routine correspondence.</P>
                        <P>
                            (a) 
                            <E T="03">Requirements for all pleadings.</E>
                             All pleadings filed with the Board must—
                        </P>
                        <P>(1) Include a caption and title.</P>
                        <P>(2) Include a certificate of service containing—</P>
                        <P>(i) The date and manner of service;</P>
                        <P>(ii) The names of persons served; and</P>
                        <P>(iii) Their mail or electronic mail addresses or the addresses of the places of delivery, as appropriate for the manner of service.</P>
                        <P>
                            (3) Include a signature of the party (or their attorney or lay representative) and date of signature. Pleadings filed by an attorney, lay representative or self-represented party via the Board's case 
                            <PRTPAGE P="8537"/>
                            management system will be deemed to be signed by that person.
                        </P>
                        <P>(4) Conform to standard letter dimensions (8.5 x 11 inches).</P>
                        <P>
                            (b) 
                            <E T="03">Redacted filings and exhibits.</E>
                             Any person who files a pleading, exhibit, or other document that contains an individual's social security number, taxpayer-identification number, or birth date; the name of an individual known to be a minor; or a financial-account number, must redact all such information, except the last four digits of the social security number and taxpayer-identification number; the year of the individual's birth; the minor's initials; and the last four digits of the financial-account number.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Nonelectronic filings.</E>
                             All nonelectronic pleadings filed with the Board must be secured at the top. For each pleading filed with the Board, the original and two legible copies must be submitted. Nonelectronic filings must be sent to the U.S. Department of Labor, Benefits Review Board, ATTN: Office of the Clerk of the Appellate Boards (OCAB), 200 Constitution Ave. NW, Washington, DC 20210-0001, or otherwise presented to the Clerk.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Electronic filings.</E>
                             (1) Except as provided in paragraph (d)(2) of this section, beginning on March 11, 2024, attorneys and lay representatives must be registered with the Board's electronic case management system and file all pleadings, exhibits, and other documents with the Board through this system (e-file). All e-filed documents must be in Portable Document Format (PDF). The Board prefers that pleadings be filed in text-searchable PDF format. Paper copies are not required unless requested by the Board.
                        </P>
                        <P>(2) Attorneys and lay representatives may request an exemption (pursuant to § 802.219) for good cause shown. Such a request must include a detailed explanation why e-filing or acceptance of e-service should not be required.</P>
                        <P>(3) Self-represented parties may file pleadings, exhibits, and other documents in electronic or nonelectronic form in accordance with paragraph (c) or (d) of this section.</P>
                        <P>(4) A document filed electronically is a written paper for purposes of this Part.</P>
                        <P>(5) A person who is adversely affected by a technical failure in connection with filing or receipt of an electronic document may seek appropriate relief from the Board under § 802.219. If a technical malfunction or other issue prevents access to the Board's case management system for a protracted period, the Board by special order may provide appropriate relief pending restoration of electronic access.</P>
                        <P>
                            (e) 
                            <E T="03">Special rules for notices of appeal.</E>
                             (1) Except as otherwise provided in this section, a notice of appeal is considered to have been filed only as of the date it is received by the office of the Clerk of the Board.
                        </P>
                        <P>(2) A notice of appeal submitted to any other agency or subdivision of the Department of Labor or of the U.S. Government or any state government, and subsequently received by the office of the Clerk of the Board, will be considered filed with the Clerk of the Board as of the date it was received by the other governmental unit if the Board finds in its discretion that it is in the interest of justice to do so.</P>
                        <P>(3) If the notice of appeal is sent by mail or commercial carrier and the fixing of the date of delivery as the date of filing would result in a loss or impairment of appeal rights, it will be considered to have been filed as of the date of mailing or the date of delivery to the commercial carrier.</P>
                        <P>(i) For notices sent by mail, the date appearing on the U.S. Postal Service postmark (when available and legible) will be prima facie evidence of the date of mailing. If there is no such postmark or it is not legible, other evidence such as, but not limited to, certified mail receipts, certificates of service, and affidavits, may be used to establish the mailing date.</P>
                        <P>(ii) For notices sent by commercial carrier, the date of delivery to the carrier may be demonstrated by the carrier's receipt or tracking information.</P>
                        <P>(4) If the notice of appeal is electronically filed through the Board's case management system, it is considered received by the office of the Clerk of the Board as of the date and time recorded by the system under § 802.221(c).</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="20" PART="802">
                    <AMDPAR>6. Add § 802.223 to subpart B to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 802.223</SECTNO>
                        <SUBJECT> Service requirements.</SUBJECT>
                        <P>This section prescribes rules and procedures for serving pleadings (including notices of appeal, petitions for review, and response briefs, additional briefs, and motions), exhibits, and other documents including routine correspondence on other parties and representatives.</P>
                        <P>(a) A copy of any document filed with the Board must be served on each party and the Solicitor of Labor by the party filing the document.</P>
                        <P>
                            (b) 
                            <E T="03">Manner of service.</E>
                             (1) Nonelectronic service may be completed by:
                        </P>
                        <P>(i) Personal delivery;</P>
                        <P>(ii) Mail; or</P>
                        <P>(iii) Commercial delivery.</P>
                        <P>(2) Electronic service may be completed by:</P>
                        <P>(i) Electronic mail, if consented to in writing by the person served; or</P>
                        <P>(ii) Sending it to a user registered with the Board's electronic case management system by filing via this system. A person who registers to use the Board's case management system is deemed to have consented to accept service through the system.</P>
                        <P>
                            (c) 
                            <E T="03">When service is effected.</E>
                             (1) Service by personal delivery is effected on the date the document is delivered to the recipient.
                        </P>
                        <P>(2) Service by mail or commercial carrier is effected on mailing or delivery to the carrier.</P>
                        <P>(3) Service by electronic means is effected on sending.</P>
                        <P>
                            (d) 
                            <E T="03">Date of receipt for electronic documents.</E>
                             Unless the party making service is notified that the document was not received by the party served—
                        </P>
                        <P>(1) A document filed via the Board's case management system is considered received by registered users on the date it is sent by the system; and</P>
                        <P>(2) A document served via electronic mail is considered received by the recipient on the date it is sent.</P>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <P>Signed in Washington, DC.</P>
                    <NAME>Julie A. Su,</NAME>
                    <TITLE>Acting Secretary of Labor.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-01991 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4510-FN-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Food and Drug Administration</SUBAGY>
                <CFR>21 CFR Part 73</CFR>
                <DEPDOC>[Docket No. FDA-2018-C-4117]</DEPDOC>
                <SUBJECT>Sensient Colors, LLC.; Filing of Color Additive Petition</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notification of petition.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA or we) is announcing that we have filed a petition, submitted by Sensient Colors, LLC., proposing that we amend our color additive regulations to provide for the safe use of butterfly pea flower extract in ready-to-eat cereals, crackers and snack mixes, and chips at levels consistent with good manufacturing practice.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The color additive petition was filed on December 5, 2023.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        For access to the docket to read background documents or 
                        <PRTPAGE P="8538"/>
                        comments received, go to 
                        <E T="03">https://www.regulations.gov</E>
                         and insert the docket number found in brackets in the heading of this document into the “Search” box and follow the prompts, and/or go to the Dockets Management Staff, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Stephen DiFranco, Center for Food Safety and Applied Nutrition, Food and Drug Administration, 5001 Campus Dr., College Park, MD 20740, 240-402-2710.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Under the Federal Food, Drug, and Cosmetic Act (section 721(d)(1) (21 U.S.C. 379e(d)(1))), we are giving notice that we have filed a color additive petition (CAP 4C0328), submitted by Exponent, Inc., on behalf of Sensient Colors, LLC., 1150 Connecticut Ave. NW, Suite 1100, Washington, DC 20036. The petition proposes to amend the color additive regulations in § 73.69 (21 CFR 73.69) 
                    <E T="03">Listing of Color Additives Exempt from Certification: Butterfly pea flower extract</E>
                     to expand the safe use of butterfly pea flower extract to include ready-to-eat cereals, crackers and snack mixes, and chips at levels consistent with good manufacturing practice.
                </P>
                <P>The petitioner claims that this action is categorically excluded under 21 CFR 25.32(k) because the substance is intended to remain in food through ingestion by consumers and is not intended to replace macronutrients in food. In addition, the petitioner states that, to their knowledge, no extraordinary circumstances exist. If FDA determines a categorical exclusion applies, neither an environmental assessment nor an environmental impact statement is required. If FDA determines a categorical exclusion does not apply, we will request an environmental assessment and make it available for public inspection.</P>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02576 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4164-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF JUSTICE</AGENCY>
                <SUBAGY>Drug Enforcement Administration</SUBAGY>
                <CFR>21 CFR Part 1301</CFR>
                <DEPDOC>[Docket No. DEA-1043]</DEPDOC>
                <RIN>RIN 1117-AB82</RIN>
                <SUBJECT>Conforming Amendment Regarding the Veterinary Medicine Mobility Act of 2014</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Drug Enforcement Administration (DEA), Department of Justice.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Veterinary Medicine Mobility Act of 2014 (VMMA), which became law on August 1, 2014, amended the Controlled Substances Act to address separate registration requirements for veterinarians. The VMMA allows a veterinarian to transport and dispense controlled substances in the usual course of veterinary practice at a site other than the veterinarian's registered principal place of business or professional practice without obtaining a separate registration, subject to certain limitations. The Drug Enforcement Administration is amending its regulations to codify the VMMA. This rule merely conforms DEA regulations to statutory amendments of the Controlled Substances Act that have already taken effect and makes no substantive change to existing legal requirements.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective on February 8, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Scott A. Brinks, Regulatory Drafting and Policy Support Section, Diversion Control Division, Drug Enforcement Administration; Telephone: (571) 776-3882.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Legal Authority</HD>
                <P>
                    The Drug Enforcement Administration (DEA) implements and enforces the Comprehensive Drug Abuse Prevention and Control Act of 1970, often referred to as the Controlled Substances Act (CSA) and the Controlled Substances Import and Export Act, as amended.
                    <SU>1</SU>
                    <FTREF/>
                     The CSA and its implementing regulations are designed to prevent, detect, and eliminate the diversion of controlled substances and listed chemicals into the illicit market while providing for the legitimate medical, scientific, research, and industrial needs of the United States. DEA publishes the implementing regulations for these statutes in 21 CFR parts 1300 to 1399.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         21 U.S.C. 801-971.
                    </P>
                </FTNT>
                <P>
                    On August 1, 2014, the President signed the Veterinary Medicine Mobility Act of 2014 (VMMA) into law as Public Law 113-143.
                    <SU>2</SU>
                    <FTREF/>
                     The VMMA amended section 302(e) of the CSA to address separate registration requirements for veterinarians. Specifically, the VMMA redesignated 21 U.S.C. 822(e) as 21 U.S.C. 822(e)(1) and added a new paragraph, 21 U.S.C. 822(e)(2). The newly added 21 U.S.C. 822(e)(2) provides that “. . . a registrant who is a veterinarian shall not be required to have a separate registration in order to transport and dispense controlled substances in the usual course of veterinary practice at a site other than the registrant's registered principal place of business or professional practice, so long as the site of transporting and dispensing is located in a State where the veterinarian is licensed to practice veterinary medicine and is not a principal place of business or professional practice.” In this final rule, DEA is amending its regulations to conform to the change to the CSA made by the VMMA.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Public Law 113-143, 128 Stat. 1750 (2014).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Regulatory Analysis</HD>
                <HD SOURCE="HD2">Administrative Procedure Act</HD>
                <P>
                    Under the Administrative Procedure Act (APA),
                    <SU>3</SU>
                    <FTREF/>
                     agencies generally offer interested parties the opportunity to comment on proposed regulations before they become effective. However, an agency may find good cause to exempt a rule from certain provisions of the APA, including those requiring the publication of a prior notice of proposed rulemaking and the opportunity for public comment, if such actions are determined to be unnecessary, impracticable, or contrary to the public interest. DEA finds there is good cause within the meaning of the APA to issue this amendment as a final rule without opportunity for public comment and with an immediate effective date because such comment is unnecessary.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         5 U.S.C. 553.
                    </P>
                </FTNT>
                <P>This final rule amends DEA regulations simply to incorporate the provisions of the VMMA. The legal requirements articulated in this final rule are already in effect by virtue of the VMMA. This rule merely incorporates the statutory provision into DEA regulations.</P>
                <P>
                    DEA is publishing this as a final rule because notice of proposed rulemaking and solicitation of public comment is 
                    <PRTPAGE P="8539"/>
                    unnecessary.
                    <SU>4</SU>
                    <FTREF/>
                     Because the statutory change at issue has been in effect since August 1, 2014, DEA finds good cause exists to make this rule effective immediately upon publication.
                    <SU>5</SU>
                    <FTREF/>
                     Therefore, DEA is issuing this amendment as a final rule, effective upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         5 U.S.C. 553(b)(B) (relating to notice and comment procedures). “[W]hen regulations merely restate the statute they implement, notice-and-comment procedures are unnecessary.” 
                        <E T="03">Gray Panthers Advocacy Comm.</E>
                         v. 
                        <E T="03">Sullivan,</E>
                         936 F.2d 1284, 1291 (D.C. Cir. 1991); 
                        <E T="03">see also Komjathy</E>
                         v. 
                        <E T="03">Nat'l Transp. Safety Bd.,</E>
                         832 F.2d 1294, 1296 (D.C. Cir. 1987) (per curiam) (notice-and-comment procedures are not required when a rule “does no more than repeat, virtually verbatim, the statutory grant of authority”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         5 U.S.C. 553(d).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">Executive Orders 12866, 13563, and 14094 (Regulatory Review)</HD>
                <P>DEA has determined that this rulemaking is not a “significant regulatory action” under section 3(f) of Executive Order 12866, Regulatory Planning and Review. Accordingly, this final rule has not been submitted to the Office of Management and Budget (“OMB”) for review. This final rule has been drafted and reviewed in accordance with Executive Order 12866, “Regulatory Planning and Review,” section 1(b), Principles of Regulation; Executive Order 13563, “Improving Regulation and Regulatory Review,” section 1(b), General Principles of Regulation; and Executive Order 14094, “Modernizing Regulatory Review.”</P>
                <P>As stated above, this final rule amends DEA regulations only to the extent necessary to be consistent with current Federal law, as modified by the VMMA. DEA has no discretion with respect to this amendment. The legal requirements in this final rule have been in effect since 2014, when the VMMA became law. DEA anticipates all affected persons are operating in accordance with the VMMA and this codification will have no economic impact.</P>
                <HD SOURCE="HD2">Executive Order 12988, Civil Justice Reform</HD>
                <P>This final rule meets the applicable standards set forth in sections 3(a) and 3(b)(2) of E.O. 12988, Civil Justice Reform, to eliminate ambiguity, minimize litigation, establish clear legal standards, and reduce burden.</P>
                <HD SOURCE="HD2">Executive Order 13132, Federalism</HD>
                <P>This final rule does not have federalism implications warranting the application of E.O. 13132. The final rule does not have substantial direct effects on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <HD SOURCE="HD2">Executive Order 13175, Consultation and Coordination With Indian Tribal Governments</HD>
                <P>This final rule does not have tribal implications warranting the application of E.O. 13175. It does not have substantial direct effects on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.</P>
                <HD SOURCE="HD2">Regulatory Flexibility Act</HD>
                <P>The Regulatory Flexibility Act (RFA) (5 U.S.C. 601-612) applies to rules that are subject to notice and comment under section 553(b) of the APA. As explained above, DEA determined that there is good cause to exempt this final rule from notice and comment. Consequently, the RFA does not apply to this final rule. In any event, as explained above, this rule is a conforming amendment that makes no change in the status quo.</P>
                <HD SOURCE="HD2">Unfunded Mandates Reform Act of 1995</HD>
                <P>
                    In accordance with the Unfunded Mandates Reform Act (UMRA) of 1995, 2 U.S.C. 1501 
                    <E T="03">et seq.,</E>
                     DEA has determined that this action will not result in any Federal mandate that may result in the expenditure by State, local, and Tribal Governments, in the aggregate, or by the private sector, of $100 million or more (adjusted for inflation) in any one year. Therefore, neither a Small Government Agency plan nor any other action is required under UMRA of 1995.
                </P>
                <HD SOURCE="HD2">Paperwork Reduction Act of 1995</HD>
                <P>This final rule does not involve a collection of information requirement under the Paperwork Reduction Act, 44 U.S.C. 3501-21. This final rule would not impose recordkeeping or reporting requirements on State or local governments, individuals, businesses, or organizations.</P>
                <HD SOURCE="HD2">Congressional Review Act</HD>
                <P>This is not a major rule as defined by the Congressional Review Act (CRA), 5 U.S.C. 804. However, pursuant to the CRA, DEA is submitting a copy of this final rule to both Houses of Congress and to the Comptroller General.</P>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Drug Enforcement Administration was signed on January 29, 2024, by Administrator Anne Milgram. That document with the original signature and date is maintained by DEA. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DEA Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of DEA. This administrative process in no way alters the legal effect of this document upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <NAME>Scott Brinks,</NAME>
                    <TITLE>Federal Register Liaison Officer, Drug Enforcement Administration.</TITLE>
                </SIG>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects 21 CFR Part 1301</HD>
                    <P>Administrative practice and procedure, Drug traffic control, Exports, Imports, Security measures.</P>
                </LSTSUB>
                <P>For the reasons stated above, 21 CFR part 1301 is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 1301—REGISTRATION OF MANUFACTURERS, DISTRIBUTORS, AND DISPENSERS OF CONTROLLED SUBSTANCES</HD>
                </PART>
                <REGTEXT TITLE="21" PART="1301">
                    <AMDPAR>1. The authority citation for part 1301 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>21 U.S.C. 821, 822, 823, 824, 831, 871(b), 875, 877, 886a, 951, 952, 956, 957, 958, 965 unless otherwise noted.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="21" PART="1301">
                    <AMDPAR>2. In § 1301.12, add paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1301.12</SECTNO>
                        <SUBJECT> Separate registrations for separate locations</SUBJECT>
                        <STARS/>
                        <P>(c) As provided in 21 U.S.C. 822(e)(2), a registrant who is a veterinarian may transport and dispense controlled substances in the usual course of veterinary practice at a site other than the registrant's registered principal place of business or professional practice without obtaining a separate registration so long as the site of transporting and dispensing is located in a State where the veterinarian is licensed to practice veterinary medicine and is not a principal place of business or professional practice.</P>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02322 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4410-09-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="8540"/>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Parts 271 and 272</CFR>
                <DEPDOC>[EPA-R08-RCRA-2023-0424; FRL 11356-01-R8]</DEPDOC>
                <SUBJECT>South Dakota: Final Authorization of State Hazardous Waste Management Program Revisions and Incorporation by Reference</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Direct final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The State of South Dakota Department of Agriculture and Natural Resources has applied to the Environmental Protection Agency (EPA) for final authorization of the changes to its hazardous waste program under the Resource Conservation and Recovery Act (RCRA). The EPA has determined that these changes satisfy all requirements needed to qualify for final authorization, and is authorizing the State's changes through this direct final action. The EPA uses the regulations entitled, “Approved State Hazardous Waste Management Programs” to provide notice of the authorization status of State programs and to incorporate by reference those provisions of State statutes and regulations that will be subject to the EPA's inspection and enforcement. This rule also codifies in the regulations the approval of South Dakota's hazardous waste management program and incorporates by reference authorized provisions of the State's regulations.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        This direct final rule is effective on April 8, 2024, unless EPA receives adverse written comment by March 11, 2024. If the EPA receives any such comment, we will publish a timely withdrawal of this direct final rule in the 
                        <E T="04">Federal Register</E>
                         informing the public that the rule will not take effect. The Director of the Federal Register approves the incorporation by reference as of April 8, 2024, in accordance with 5 U.S.C. 552(a) and 1 CFR part 51.
                    </P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Submit your comments, identified by Docket ID No. EPA-R08-RCRA-2023-0424; FRL 11356-01-R8 by one of the following methods:</P>
                    <P>
                        1. 
                        <E T="03">Federal eRulemaking Portal: https://www.regulations.gov.</E>
                         Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        2. 
                        <E T="03">Email: lin.moye@epa.gov.</E>
                    </P>
                    <P>
                        3. 
                        <E T="03">Fax:</E>
                         (303) 312-6341 (prior to faxing, please notify the EPA contact listed below).
                    </P>
                    <P>
                        4. 
                        <E T="03">Mail, Hand Delivery or Courier:</E>
                         Moye Lin, Resource Conservation and Recovery Act Branch, EPA Region 8, Mail Code 8LCR-RC, 1595 Wynkoop Street, Denver, Colorado 80202-1129. Courier or hand deliveries are only accepted during the Regional Office's normal hours of operation. The public is advised to call in advance to verify business hours. Special arrangements should be made for deliveries of boxed information.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         EPA must receive your comments by March 11, 2024. Direct your comments to EPA-R08-RCRA-2023-0424; FRL 11356-01-R8. The EPA's policy is that all comments received will be included in the public docket without change and may be available online at 
                        <E T="03">https://www.regulations.gov,</E>
                         including any personal information provided, unless the comment includes information claimed to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. Do not submit information that you consider to be CBI or otherwise protected through 
                        <E T="03">https://regulations.gov</E>
                         or email. The Federal 
                        <E T="03">https://www.regulations.gov</E>
                         website is an “anonymous access” system, which means the EPA will not know your identity or contact information unless you provide it in the body of your comment. If you send an email comment directly to the EPA without going through 
                        <E T="03">https://www.regulations.gov,</E>
                         your email address will be automatically captured and included as part of the comment that is placed in the public docket and made available on the internet. If you submit an electronic comment, EPA recommends that you include your name and other contact information in the body of your comment with any CD you submit. If EPA cannot read your comment due to technical difficulties and cannot contact you for clarification, EPA may not be able to consider your comment. Electronic files should avoid the use of special characters, any form of encryption, and be free of any defects or viruses.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         All documents in the docket are listed in the 
                        <E T="03">https://www.regulations.gov</E>
                         index. Although listed in the index, some information is not publicly available, 
                        <E T="03">e.g.,</E>
                         CBI or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, will be publicly available only in hard copy. Publicly available docket materials are available electronically through 
                        <E T="03">https://www.regulations.gov.</E>
                         For alternative access to docket materials, please contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Moye Lin, Resource Conservation and Recovery Act Branch, EPA Region 8, 1595 Wynkoop Street, Denver, Colorado 80202-1129; phone number (303) 312-6667; Email address: 
                        <E T="03">lin.moye@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Authorization of Revisions to South Dakota's Hazardous Waste Program</HD>
                <HD SOURCE="HD2">A. Why are revisions to State programs necessary?</HD>
                <P>States which have received final authorization from EPA under RCRA section 3006(b), 42 U.S.C. 6926(b), must maintain a hazardous waste program that is equivalent to, consistent with, and no less stringent than the Federal program. As the Federal program changes, States must change their programs and ask EPA to authorize the changes. Changes to State programs may be necessary when Federal or State statutory or regulatory authority is modified or when certain other changes occur. Most commonly, States must change their programs because of changes to EPA's regulations in title 40 of the Code of Federal Regulations (CFR), parts 124, 260 through 268, 270, 273, and 279.</P>
                <HD SOURCE="HD2">B. What authorization decisions has the EPA made in this rule?</HD>
                <P>
                    On January 6, 2023, South Dakota submitted a final complete program revision application seeking authorization of changes to its hazardous waste program. The EPA concludes that South Dakota's application to revise its authorized program meets all the statutory and regulatory requirements established by RCRA. Therefore, we grant South Dakota final authorization to operate its hazardous waste program with the changes described in the authorization application. South Dakota has responsibility for permitting Treatment, Storage, and Disposal Facilities (TSDFs), and for carrying out the aspects of the RCRA program described in its revised program application, subject to the limitations of the Hazardous and Solid Waste Amendments of 1984 (HSWA), for all areas within the State, except for (1) lands located within formal Indian Reservations within or abutting the State of South Dakota, including the Cheyenne River Indian Reservation, Crow Creek Indian Reservation, Flandreau Indian Reservation, Lower Brule Indian Reservation, Pine Ridge Indian Reservation, Rosebud Indian Reservation, Sisseton-Wahpeton Indian Reservation, Standing Rock Indian Reservation, and Yankton Indian Reservation, (2) any land held in trust 
                    <PRTPAGE P="8541"/>
                    by the United States for an Indian tribe, (3) and any other land, whether on or off a reservation that qualifies as “Indian country” within the meaning of 18 U.S.C. 1151. New Federal requirements and prohibitions imposed by Federal regulations that EPA promulgates under the authority of HSWA take effect in authorized States before they are authorized for the requirements. Thus, EPA will implement those requirements and prohibitions in South Dakota, including issuing permits, until South Dakota is authorized to do so.
                </P>
                <HD SOURCE="HD2">C. What is the effect of this authorization decision?</HD>
                <P>The effect of this decision is that a facility in South Dakota subject to RCRA will have to comply with the authorized State requirements instead of the equivalent Federal requirements in order to comply with RCRA. The State of South Dakota will continue to have enforcement responsibilities under its State hazardous waste program for violations of such program, but the EPA retains its authority under RCRA sections 3007, 3008, 3013, and 7003, which include, among others, authority to:</P>
                <P>• Conduct inspections and require monitoring, tests, analyses, or reports;</P>
                <P>• Enforce RCRA requirements; suspend or revoke permits; and</P>
                <P>• Take enforcement actions after notice to and consultation with the State.</P>
                <P>This action to approve these provisions would not impose additional requirements on the regulated community because the regulations for which the State of South Dakota is requesting authorization are already effective under State law and are not changed by the act of authorization.</P>
                <HD SOURCE="HD2">D. Why is the EPA using a direct final rule?</HD>
                <P>
                    The EPA is publishing this rule without a prior proposal because we view this as a noncontroversial action and anticipate no adverse comment. However, in the “Proposed Rules” section of this 
                    <E T="04">Federal Register</E>
                    , we are publishing a separate document that will serve as the proposed rule allowing the public an opportunity to comment. We will not institute a second comment period on this action. Any parties interested in commenting must do so at this time. For further information about commenting on this rule, see the 
                    <E T="02">ADDRESSES</E>
                     section of this document.
                </P>
                <HD SOURCE="HD2">E. What happens if EPA receives comments opposing this action?</HD>
                <P>
                    If EPA receives comments that oppose this authorization, we will publish a timely withdrawal in the 
                    <E T="04">Federal Register</E>
                     informing the public that this direct final rule will not take effect. We will address all public comments in a later 
                    <E T="04">Federal Register</E>
                    . You will not have another opportunity to comment; therefore, if you want to comment on this action, you must do so at this time.
                </P>
                <HD SOURCE="HD2">F. For what has South Dakota previously been authorized?</HD>
                <P>South Dakota initially received final authorization on October 19, 1984, effective November 2, 1984 (49 FR 41038), to implement the RCRA hazardous waste management program. We granted authorization for changes to their program on: April 17, 1991, effective June 17, 1991 (56 FR 15503); September 8, 1993, effective November 8, 1993 (FR 47216); January 10, 1994, effective March 11, 1994 (59 FR 1275); July 24, 1996, effective September 23, 1996 (61 FR 38392); May 9, 2000, effective June 8, 2000 (65 FR 26755); April 23, 2004, effective May 24, 2004 (69 FR 21962); March 8, 2006, effective March 8, 2006 (71 FR 11533); August 8, 2012, effective August 8, 2012 (77 FR 47302); and June 24, 2016, effective August 23, 2016 (81 FR 41222).</P>
                <HD SOURCE="HD2">G. What changes is EPA authorizing with this action?</HD>
                <P>On January 6, 2023, the State of South Dakota submitted a final complete program revision application, seeking authorization of their changes in accordance with 40 CFR 271.21. We now make a final decision, subject to receipt of written comments that oppose this action, that South Dakota's hazardous waste program satisfies all of the requirements necessary to qualify for final authorization. Therefore, we grant South Dakota final authorization for the following changes:</P>
                <HD SOURCE="HD3">1. Program Revision Changes for Federal Rules</HD>
                <P>The State of South Dakota revisions consist of regulations which specifically govern Federal hazardous waste revisions promulgated June 29, 1995 (60 FR 33912; Checklist 144), October 30, 2008 (73 FR 64668; Checklist 219), June 15, 2010 (75 FR 33712; Checklist 224), and from July 1, 2013, through June 30, 2019 (RCRA Clusters XXIII-XXVII), except for the final rules published on January 3, 2018 (83 FR 420; Checklist 239), and on February 22, 2019 (84 FR 5816; Checklist 241). The State requirements from its Hazardous Waste Rules, Administrative Rules of South Dakota (ARSD), Article 74:28, effective April 19, 2021, are included in the chart below.</P>
                <GPOTABLE COLS="3" OPTS="L2,nj,tp0,i1" CDEF="s100,r50,r50">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Description of Federal requirement</CHED>
                        <CHED H="1">Federal Register date and page</CHED>
                        <CHED H="1">Analogous State authority</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Removal of Legally Obsolete Rules (Checklist 144)</ENT>
                        <ENT>60 FR 33912; 6/8/95</ENT>
                        <ENT>ARSD 74:28:22:01, 74:28:26:01, and 74:28:27:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Revisions to the Definition of Solid Waste (Checklist 219)</ENT>
                        <ENT>73 FR 64668; 10/30/08</ENT>
                        <ENT>ARSD 74:28:21:02, 74:28:22:01, and 74:28:26:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Withdrawal of the Emission Comparable Fuel Exclusion (Checklist 224)</ENT>
                        <ENT>75 FR 33712; 6/15/10</ENT>
                        <ENT>ARSD 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Conditional Exclusions for Solvent Contaminated Wipes (Checklist 229)</ENT>
                        <ENT>78 FR 46448; 7/31/13</ENT>
                        <ENT>ARSD 74:28:21:02 and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Conditional Exclusion for Carbon Dioxide (CO2) Streams in Geologic Sequestration Activities (Checklist 230)</ENT>
                        <ENT>79 FR 350; 1/3/14</ENT>
                        <ENT>ARSD 74:28:21:02 and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Hazardous Waste Electronic Manifest Rule (Checklist 231)</ENT>
                        <ENT>79 FR 7518; 2/7/14</ENT>
                        <ENT>ARSD 74:28:21:01(3)(b)(i) and (xii), 74:28:21:01(20), 74:28:21:02, 74:28:23:01, 74:28:24:01, 74:28:25:01, and 74:28:28:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Revisions to the Export Provisions of the Cathode Ray Tube (CRT) Rule (Checklist 232)</ENT>
                        <ENT>79 FR 36220; 6/26/14</ENT>
                        <ENT>74:28:21:01(3)(b)(xi), 74:28:21:01(20), 74:28:21:02, and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Changes affecting all non-waste determinations and variances (Checklist 233A)</ENT>
                        <ENT>80 FR 1694; 1/13/15; 83 FR 24664; 5/30/18</ENT>
                        <ENT>ARSD 74:28:21:02.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8542"/>
                        <ENT I="01">Legitimacy-related provisions, including prohibition of sham recycling, definition of legitimacy, definition of Contained (Checklist 233B)</ENT>
                        <ENT>80 FR 1694; 1/13/15; 83 FR 24664; 5/30/18</ENT>
                        <ENT>ARSD 74:28:21:02 and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Speculative Accumulation (Checklist 233C)</ENT>
                        <ENT>80 FR 1694; 1/13/15</ENT>
                        <ENT>ARSD 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2008 DSW exclusions and non-waste determinations, including revisions from 2015 DSW final rule and 2018 DSW final rule (Checklist 233D2)</ENT>
                        <ENT>80 FR 1694; 1/13/15; 83 FR 24664; 5/30/18</ENT>
                        <ENT>ARSD 74:28:21:02, 74:28:22:01, and 74:28:26:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Remanufacturing exclusion (Checklist 233E)</ENT>
                        <ENT>80 FR 1694; 1/13/15</ENT>
                        <ENT>ARSD 74:28:21:02 and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Response to Vacaturs of the Comparable Fuels Rule and the Gasification Rule (Checklist 234)</ENT>
                        <ENT>80 FR 18777; 4/8/15</ENT>
                        <ENT>ARSD 74:28:21:02 and 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Disposal of Coal Combustion Residuals from Electric Utilities (Checklist 235)</ENT>
                        <ENT>80 FR 21302; 4/17/15</ENT>
                        <ENT>ARSD 74:28:22:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Imports and Exports of Hazardous Waste (Checklist 236)</ENT>
                        <ENT>81 FR 85696; 11/28/16; 82 FR 41015; 8/29/17; 83 FR 38263; 8/6/18</ENT>
                        <ENT>ARSD 74:28:21:01, 74:28:21:02, 74:28:22:01, 74:28:23:01, 74:28:24:01, 74:28:25:01, 74:28:27:01, 74:28:28:01, and 74:28:33:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Hazardous Waste Generator Improvements Rule (Checklist 237)</ENT>
                        <ENT>81 FR 85732; 11/28/16</ENT>
                        <ENT>ARSD 74:28:21:02, 74:28:22:01, 74:28:23:01, 74:28:24:01, 74:28:25:01, 74:28:26:01, 74:28:27:01, 74:28:28:01, 74:28:30:01, and 74:28:33:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Confidentiality Determinations for Hazardous Waste Export and Import Documents (Checklist 238)</ENT>
                        <ENT>83 FR 60894; 12/26/17</ENT>
                        <ENT>ARSD 74:28:21:01(20), 74:28:21:02, 74:28:22:01, and 74:28:23:01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Safe Management of Recalled Airbags (Checklist 240)</ENT>
                        <ENT>83 FR 61552; 11/30/18</ENT>
                        <ENT>ARSD 74:28:21:02, 74:28:22:01, and 74:28:23:01.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD3">2. State-Initiated Changes</HD>
                <P>
                    South Dakota has made amendments to its regulations that are not directly related to any of the Federal rules addressed in Item G.1 above. These State-initiated changes are either conforming changes made to existing authorized provisions, or the adoption of provisions that clarify and make the State's regulations internally consistent. The State's regulations, as amended by these provisions, provide authority which remains equivalent to and no less stringent than the Federal laws and regulations. These State-initiated changes are submitted under the requirements of 40 CFR 271.21(a) and include the following provisions from the Administrative Rules of South Dakota (ARSD), as amended, effective April 19, 2021: ARSD 74:28:21:01 introductory paragraph, 74:28:21:01(1) “Administrator”, 74:28:21:01(8) “
                    <E T="04">Federal Register</E>
                    ”, 74:28:21:01(11) “New tank system” or “new tank component”, 74:28:21:01(13) “Region”, 74:28:21:01(14) “Resource Conservation and Recovery Act”, “RCRA”, 74:28:21:01(17) “State”, 74:28:25:04, 74:28:25:05, 74:28:28:03, 74:28:28:04, 74:28:28:05, and 74:36:11:01.
                </P>
                <HD SOURCE="HD2">H. Where are the revised State rules different from the Federal rules?</HD>
                <P>The South Dakota revisions being authorized in this rule include provisions that contain purely Federal functions which are not delegable to States. The non-delegable Federal program areas include import/export requirements reserved as part of the Federal foreign relations function, and manifest registry and electronic manifest functions administered solely by the EPA. South Dakota has appropriately adopted these provisions by leaving the authority with the EPA for implementation and enforcement. The State did not make any changes that are more stringent or broader-in-scope than the Federal rules in this rulemaking. In addition, South Dakota did not change any previously more stringent or broader-in-scope provisions to be equivalent to the Federal rules.</P>
                <HD SOURCE="HD2">I. Who handles permits after the authorization takes effect?</HD>
                <P>The State of South Dakota will continue to issue permits for all the provisions for which it is authorized and will administer the permits it issues. The EPA will continue to administer any RCRA hazardous waste permits or portions of permits which we issued prior to the effective date of this authorization, until South Dakota has equivalent instruments in place. EPA will continue to implement and issue permits for HSWA requirements for which South Dakota is not yet authorized.</P>
                <HD SOURCE="HD2">J. How does this action affect Indian Country (18 U.S.C. 1151) in South Dakota?</HD>
                <P>South Dakota is not authorized to carry out its hazardous waste program in Indian country, as defined in 18 U.S.C. 1151. This includes, but is not limited to:</P>
                <P>1. Lands within the exterior boundaries of the following Indian Reservations located within or abutting the State of South Dakota:</P>
                <FP SOURCE="FP-1">a. Cheyenne River Indian Reservation</FP>
                <FP SOURCE="FP-1">b. Crow Creek Indian Reservation</FP>
                <FP SOURCE="FP-1">c. Flandreau Indian Reservation</FP>
                <FP SOURCE="FP-1">d. Lower Brule Indian Reservation</FP>
                <FP SOURCE="FP-1">e. Pine Ridge Indian Reservation</FP>
                <FP SOURCE="FP-1">f. Rosebud Indian Reservation</FP>
                <FP SOURCE="FP-1">g. Sisseton-Wahpeton Indian Reservation</FP>
                <FP SOURCE="FP-1">h. Standing Rock Indian Reservation</FP>
                <FP SOURCE="FP-1">i. Yankton Indian Reservation</FP>
                <P>2. Any land held in trust by the U.S. for an Indian tribe; and</P>
                <P>3. Any other land, whether on or off a reservation that qualifies as Indian country within the meaning of 18 U.S.C. 1151.</P>
                <P>
                    Under principles of Federal Indian law, States generally do not have authority to regulate in Indian country. 
                    <E T="03">Ala.</E>
                     v. 
                    <E T="03">Native Vill. of Venetie Tribal Gov't.,</E>
                     522 U.S. 520 n.1 (1998). Accordingly, in the absence of an express grant of authority to a State from Congress, EPA typically excludes Indian country from program delegations and authorizations to States. 
                    <E T="03">See</E>
                     RCRA Authorization regulations at 40 CFR 271.1(h) (“[I]n many cases States will lack authority to regulate activities on Indian lands.”).
                </P>
                <P>Indian country is defined by Federal statute, 18 U.S.C. 1151, as:</P>
                <P>
                    a. all land within the limits of any Indian reservation under the 
                    <PRTPAGE P="8543"/>
                    jurisdiction of the United States Government, notwithstanding the issuance of any patent, and, including rights-of-way running through the reservation;
                </P>
                <P>b. all dependent Indian communities within the borders of the United States whether within the original or subsequently acquired territory thereof, and whether within or without the limits of a State; and</P>
                <P>c. all Indian allotments, the Indian titles to which have not been extinguished, including rights-of-way running through the same.</P>
                <P>
                    It is important to note that the phrase “notwithstanding the issuance of any patent” in 18 U.S.C. 1151(a) has been interpreted by the U.S. Supreme Court to include fee patents (also known as land titles or land deeds) issued to Indians and non-Indians alike. 
                    <E T="03">See, Seymour</E>
                     v. 
                    <E T="03">Superintendent,</E>
                     368 U.S. 351, 358 (1962). Accordingly, fee-owned lands, whether owned by Indians or nonmembers of the relevant Indian tribe, which are within the exterior boundaries of Indian reservations, are Indian country. While 18 U.S.C. 1151 on its face relates to criminal jurisdiction, the U.S. Supreme Court has held that it is also relevant for civil regulatory jurisdiction. 
                    <E T="03">See, DeCoteau</E>
                     v. 
                    <E T="03">Dist. County Court,</E>
                     420 U.S. 425, 427 n.2 (1975).
                </P>
                <P>
                    In addition, Tribal trust lands located outside of formal reservations are also Indian country as defined in 18 U.S.C. 1151. For a detailed legal discussion and explanation of this interpretation of Indian country, 
                    <E T="03">see</E>
                     Letter from Jack W. McGraw, Acting Regional Administrator, United States Environmental Agency, to Steven M. Pirner, Secretary, South Dakota Department of Environment and Natural Resources (April 2, 2002), printed in 67 FR 45684 through 45687 (July 10, 2002).
                </P>
                <HD SOURCE="HD1">II. Incorporation by Reference</HD>
                <HD SOURCE="HD2">A. What is codification?</HD>
                <P>Codification is the process of including the statutes and regulations that comprise the State's authorized hazardous waste management program into the CFR. Section 3006(b) of RCRA, as amended, allows the Environmental Protection Agency (EPA) to authorize State hazardous waste management programs. The State regulations authorized by EPA supplant the Federal regulations concerning the same matter with the result that after authorization EPA enforces the authorized regulations. Infrequently, State statutory language which acts to regulate a matter is also authorized by EPA with the consequence that EPA enforces the authorized statutory provision. EPA does not authorize State enforcement authorities and does not authorize State procedural requirements. EPA codifies the authorized State program in 40 CFR part 272 and incorporates by reference State statutes and regulations that make up the approved program which is federally enforceable in accordance with Sections 3007, 3008, 3013, and 7003 of RCRA, 42 U.S.C. 6927, 6928, 6934 and 6973, and any other applicable statutory and regulatory provisions.</P>
                <HD SOURCE="HD2">B. What is the history of the codification of South Dakota's hazardous waste management program?</HD>
                <P>The EPA incorporated by reference South Dakota's authorized hazardous waste program effective March 8, 2006 (71 FR 11533), and program revisions effective August 23, 2016 (81 FR 41222). In this action, EPA is revising subpart QQ of 40 CFR part 272 to include the authorization revision actions described in this document.</P>
                <HD SOURCE="HD2">C. What codification decisions have we made in this rule?</HD>
                <P>
                    In this rule, the EPA is finalizing regulatory text that includes incorporation by reference of the authorized hazardous waste management program of the State of South Dakota. In accordance with requirements of 1 CFR 51.5, EPA is finalizing the incorporation by reference of the South Dakota rules described in the amendments to 40 CFR part 272 set forth in § 272.2101. EPA has made, and will continue to make, these documents available electronically through 
                    <E T="03">https://www.regulations.gov.</E>
                     For alternative access to docket materials, please contact the person identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this preamble.
                </P>
                <P>
                    This action codifies EPA's authorization of South Dakota's base hazardous waste management program and its revisions to that program. The codification reflects the State program that would be in effect at the time EPA's authorized revisions to the South Dakota hazardous waste management program addressed in this direct final rule become final. This action does not reopen any decision EPA previously made concerning the authorization of the State's hazardous waste management program. EPA is not requesting comments on its decisions published in the 
                    <E T="04">Federal Register</E>
                     documents referenced in section I.F of this document concerning revisions to the authorized program in South Dakota.
                </P>
                <P>The EPA is incorporating by reference EPA's approval of South Dakota's hazardous waste management program by amending subpart QQ of 40 CFR part 272. The action amends § 272.2101 and incorporates by reference South Dakota's authorized hazardous waste regulations, as amended effective April 19, 2021. Section 272.2101 also references the demonstration of adequate enforcement authority, including procedural and enforcement provisions, which provide the legal basis for the State's implementation of the hazardous waste management program. In addition, § 272.2101 references the Memorandum of Agreement, the Attorney General's Statements and the Program Description, which are evaluated as part of the approval process of the hazardous waste management program in accordance with subtitle C of RCRA.</P>
                <HD SOURCE="HD2">D. What is the effect of South Dakota's codification on enforcement?</HD>
                <P>EPA retains the authority under statutory provisions, including but not limited to, RCRA sections 3007, 3008, 3013 and 7003, and other applicable statutory and regulatory provisions to undertake inspections and enforcement actions and to issue orders in all authorized States. With respect to enforcement actions, EPA will rely on Federal sanctions, Federal inspection authorities, and Federal procedures rather than the State analogs to these provisions. Therefore, the EPA is not incorporating by reference South Dakota's inspection and enforcement authorities, nor are those authorities part of South Dakota's approved State program which operates in lieu of the Federal program. The regulation at 40 CFR 272.2101(c)(2) lists these authorities for informational purposes, and because EPA also considered them in determining the adequacy of South Dakota's procedural and enforcement authorities. South Dakota's authority to inspect and enforce the State's hazardous waste management program requirements continues to operate independently under State law.</P>
                <HD SOURCE="HD2">E. What State provisions are not part of the codification?</HD>
                <P>The public is reminded that some provisions of South Dakota's hazardous waste management program are not part of the federally authorized State program. These non-authorized provisions include:</P>
                <P>(1) Provisions that are not part of the RCRA subtitle C program because they are “broader in scope” than RCRA subtitle C (see 40 CFR 271.1(i));</P>
                <P>
                    (2) Federal rules for which South Dakota is not authorized, but which have been incorporated into the State regulations because of the way the State 
                    <PRTPAGE P="8544"/>
                    adopted Federal regulations by reference.
                </P>
                <P>(3) State procedural and enforcement authorities which are necessary to establish the ability of the State's program to enforce compliance but which do not supplant the Federal statutory enforcement and procedural authorities.</P>
                <P>State provisions that are “broader in scope” than the Federal program are not incorporated by reference in 40 CFR part 272. For reference and clarity, EPA lists in 40 CFR 272.2101(c)(3) the South Dakota statutory provisions which are “broader in scope” than the Federal program and which are not part of the authorized program being incorporated by reference. While “broader in scope” provisions are not part of the authorized program and cannot be enforced by EPA, the State may enforce such provisions under State law.</P>
                <P>South Dakota has adopted but is not authorized for the Federal Hazardous Waste Electronic Manifest User Fee Rule published January 3, 2018 (83 FR 420). Therefore, the Federal amendments to 40 CFR parts 260, 262, 263, 264, and 265 addressed by this Federal rule and included in South Dakota's adoption by reference at ARSD, sections 74:28:21:01, 74:28:21:02, 74:28:23:01, 74:28:24:01, 74:28:25:01, and 74:28:28:01, are not part of the State's authorized program included in this codification. Additionally, South Dakota, adopted the Federal Management Standards for Hazardous Waste Pharmaceuticals and Amendment to the P075 Listing for Nicotine Rule published February 22, 2019 (84 FR 5816). Therefore, the Federal amendments to 40 CFR parts 261, 262, 264, 265, 266, 268, 270, and 273 addressed by this Federal rule and included in South Dakota's adoption by reference at ARSD sections 74:28:22:01, 74:28:23:01, 74:28:25:01, 74:28:26:01, 74:28:27:01, 74:28:28:01, 74:28:30:01, and 74:28:33:01 are not part of the State's authorized program included in this codification. EPA has identified in 40 CFR 272.2101(c)(4) those Federal regulations which, while adopted by South Dakota, are not authorized by EPA.</P>
                <HD SOURCE="HD2">F. What will be the effect of codification on Federal HSWA requirements?</HD>
                <P>With respect to any requirement(s) pursuant to HSWA for which the State has not yet been authorized, and which EPA has identified as taking effect immediately in States with authorized hazardous waste management programs, EPA will enforce those Federal HSWA standards until the State is authorized for those provisions.</P>
                <P>The codification does not affect Federal HSWA requirements for which the State is not authorized. EPA has authority to implement HSWA requirements in all States, including States with authorized hazardous waste management programs, until the States become authorized for such requirements or prohibitions, unless EPA has identified the HSWA requirement(s) as an optional or as a less stringent requirement of the Federal program. A HSWA requirement or prohibition, unless identified by EPA as optional or as less stringent, supersedes any less stringent or inconsistent State provision which may have been previously authorized by EPA (50 FR 28702, July 15, 1985).</P>
                <P>Some existing State requirements may be similar to the HSWA requirements implemented by EPA. However, until EPA authorizes those State requirements, EPA enforces the HSWA requirements and not the State analogs.</P>
                <HD SOURCE="HD1">III. Administrative Requirements</HD>
                <P>
                    The Office of Management and Budget (OMB) has exempted this action from the requirements of Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011). Therefore, this action is not subject to review by OMB. This action authorizes and codifies State requirements for the purpose of RCRA section 3006 and imposes no additional requirements beyond those imposed by State law. Accordingly, I certify that this action will not have a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ). Because this action authorizes and codifies pre-existing requirements under State law and does not impose any additional enforceable duty beyond that required by State law, it does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4). For the same reason, this action also does not significantly or uniquely affect the communities of Tribal governments, as specified by Executive Order 13175 (65 FR 67249, November 9, 2000). This action will not have substantial direct effects on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government, as specified in Executive Order 13132 (64 FR 43255, August 10, 1999), because it merely authorizes and codifies State requirements as part of the State RCRA hazardous waste program without altering the relationship or the distribution of power and responsibilities established by RCRA.
                </P>
                <P>This action also is not subject to Executive Order 13045 (62 FR 19885, April 23, 1997), because it is not economically significant and it does not make decisions based on environmental health or safety risks. This rule is not subject to Executive Order 13211, “Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use” (66 FR 28355, May 22, 2001), because it is not a significant regulatory action under Executive Order 12866.</P>
                <P>
                    Under RCRA section 3006(b), EPA grants a State's application for authorization as long as the State meets the criteria required by RCRA. It would thus be inconsistent with applicable law for EPA, when it reviews a State authorization application, to require the use of any particular voluntary consensus standard in place of another standard that otherwise satisfies the requirements of RCRA. Thus, the requirements of section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) do not apply. As required by section 3 of Executive Order 12988 (61 FR 4729, February 7, 1996), in issuing this rule, EPA has taken the necessary steps to eliminate drafting errors and ambiguity, minimize potential litigation, and provide a clear legal standard for affected conduct. EPA has complied with Executive Order 12630 (53 FR 8859, March 15, 1988) by examining the takings implications of the rule in accordance with the “Attorney General's Supplemental Guidelines for the Evaluation of Risk and Avoidance of Unanticipated Takings” issued under the Executive order. This rule does not impose an information collection burden under the provisions of the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <P>
                    Executive Order 12898 (59 FR 7629, February 16, 1994) establishes Federal executive policy on environmental justice. Its main provision directs Federal agencies, to the greatest extent practicable and permitted by law, to make environmental justice part of their mission by identifying and addressing, as appropriate, disproportionately high and adverse human health or environmental effects of their programs, policies, and activities on minority populations and low-income populations in the United States. Because this rule authorizes pre-existing State rules which are at least equivalent to, and no less stringent than existing Federal requirements, and imposes no additional requirements beyond those 
                    <PRTPAGE P="8545"/>
                    imposed by State law, and there are no anticipated significant adverse human health or environmental effects, the rule is not subject to Executive Order 12898.
                </P>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. The EPA will submit a report containing this document and other required information to the U.S. Senate, the U.S. House of Representatives, and the Comptroller General of the United States prior to publication in the 
                    <E T="04">Federal Register</E>
                    . A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2). This action will be effective April 8, 2024.
                </P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> This rule is issued under the authority of Sections 2002(a), 3006 and 7004(b) of the Solid Waste Disposal Act as amended, 42 U.S.C. 6912(a), 6926, 6974(b).</P>
                </AUTH>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects</HD>
                    <CFR>40 CFR Part 271</CFR>
                    <P>Environmental protection, Administrative practice and procedure, Confidential business information, Hazardous waste, Hazardous waste transportation, Indian lands, Intergovernmental relations, Penalties, Reporting and recordkeeping requirements.</P>
                    <CFR>40 CFR Part 272</CFR>
                    <P>Hazardous materials transportation, Hazardous waste, Incorporation by reference, Intergovernmental relations, Water pollution control, Water supply.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: January 30, 2024.</DATED>
                    <NAME>KC Becker,</NAME>
                    <TITLE>Regional Administrator, Region 8.</TITLE>
                </SIG>
                <P>For the reasons set forth in the preamble, under the authority at 42 U.S.C. 6912(a), 6926, and 6974(b), EPA is granting final authorization under 40 CFR part 271 to the State of South Dakota for revisions to its hazardous waste program under the Resource Conservation and Recovery Act and is amending 40 CFR part 272 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 272—APPROVED STATE HAZARDOUS WASTE MANAGEMENT PROGRAMS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="272">
                    <AMDPAR>1. The authority citation for part 272 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>Secs. 2002(a), 3006, and 7004(b) of the Solid Waste Disposal Act, as amended by the Resource Conservation and Recovery Act, as amended, 42 U.S.C. 6912(a), 6926, and 6974(b).</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="40" PART="272">
                    <AMDPAR>2. Revise § 272.2101 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 272.2101 </SECTNO>
                        <SUBJECT> South Dakota State-administered program: Final authorization.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">History of the State of South Dakota authorization.</E>
                             Pursuant to section 3006(b) of RCRA, 42 U.S.C. 6926(b), South Dakota has final authorization for the following elements as submitted to EPA in South Dakota's base program application for final authorization which was approved by EPA effective on November 2, 1984. Subsequent program revision applications were approved effective on June 17, 1991, November 8, 1993, March 11, 1994, September 23, 1996, June 8, 2000, May 24, 2004, March 8, 2006, August 8, 2012, August 23, 2016, and April 8, 2024.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Enforcement authority.</E>
                             The State of South Dakota has primary responsibility for enforcing its hazardous waste management program. However, EPA retains the authority to exercise its inspection and enforcement authorities in accordance with sections 3007, 3008, 3013, and 7003 of RCRA, 42 U.S.C. 6927, 6928, 6934, and 6973, and any other applicable statutory and regulatory provisions, regardless of whether the State has taken its own actions, as well as in accordance with other statutory and regulatory provisions.
                        </P>
                        <P>
                            (c) 
                            <E T="03">State statutes and regulations</E>
                            —(1) 
                            <E T="03">Incorporation by reference.</E>
                             The South Dakota regulations cited in paragraph (c)(1)(i) of this section are incorporated by reference as part of the hazardous waste management program under Subtitle C of RCRA, 42 U.S.C. 6921 
                            <E T="03">et seq.</E>
                             The Director of the Federal Register in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. This material is available for inspection at the EPA and at the National Archives and Records Administration (NARA). You may inspect a copy at EPA Region 8, 1595 Wynkoop Street, Denver, Colorado, phone number (303) 312-6667. For information on the availability of this material at NARA, email: 
                            <E T="03">fr.inspection@nara.gov,</E>
                             or go to: 
                            <E T="03">https://www.archives.gov/federal-register/cfr/ibr-locations.html.</E>
                             You may obtain copies of the South Dakota regulations that are incorporated by reference in this paragraph from South Dakota Legislative Research Council, 3rd Floor, State Capitol, 500 East Capitol Avenue, Pierre, SD 57501, phone number 605-773-3251.
                        </P>
                        <P>(i) EPA-Approved South Dakota Regulatory Requirements Applicable to the Hazardous Waste Management Program, dated June 2022.</P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (2) 
                            <E T="03">Legal basis.</E>
                             The following provisions provide the legal basis for the State's implementation of the hazardous waste program, but they are not being incorporated by reference and do not replace Federal authorities:
                        </P>
                        <P>(i) South Dakota Codified Laws (SDCL), as amended, 2021 Revision, Title 1, State Affairs and Government: Chapter 1-26, Administrative Procedures and Rules, sections 1-26-1(1), 1-26-1(4), 1-26-1(8) introductory paragraph, 1-26-1(8)(a), 1-26-2, 1-26-6.6, 1-26-16 through 1-26-19, 1-26-19.1, 1-26-19.2, 1-26-21, 1-26-27, 1-26-29, 1-26-30, 1-26-30.1, 1-26-30.2, 1-26-30.4, 1-26-31, 1-26-31.1, 1-26-31.2, 1-26-31.4, 1-26-35 and 1-26-36; Chapter 1-27, Public Records and Files, sections 1-27-1, 1-27-3, 1-27-9(2) and 1-27-28, 1-27-31; Chapter 1-32, Executive Reorganization, section 1-32-1(1); Chapter 1-41, Department of Agriculture and Natural Resources, sections 1-41-3.4, 1-41-18, 1-41-24 and 1-41-25.1.</P>
                        <P>(ii) SDCL, as amended, 2021 Revision, Title 15, Civil Procedure: Chapter 15-6, Rules of Procedure in Circuit Courts, section 15-6-24(a)-(c).</P>
                        <P>(iii) SDCL, as amended, 2021 Revision, Title 19, Evidence: Chapter 19-13, Privileges, sections 19-19-502(1), 19-19-502(5), 19-19-502(b), 19-19-507 and 19-19-509.</P>
                        <P>(iv) SDCL, as amended, 2021 Revision, Title 21, Judicial Remedies: Chapter 21-8, Injunction, section 21-8-1.</P>
                        <P>(v) SDCL, as amended, 2021 Revision, Title 22, Crimes: Chapter 22-6, Authorized Punishments, sections 22-6-1 introductory paragraph and 22-6-1(7).</P>
                        <P>(vi) SDCL, as amended, 2021 Revision, Title 23, Law Enforcement: Chapter 23-5, Criminal Identification, sections 23-5-1, 23-5-10(1), 23-5-10(3), 23-5-10(4) and 23-5-11 first sentence; Chapter 23-6, Criminal Statistics, section 23-6-4.</P>
                        <P>(vii) SDCL, as amended, 2021 Revision, Title 34, Public Health and Safety: Chapter 34-21, Radiation and Uranium Resources Exposure Control, section 34-21-2(7).</P>
                        <P>
                            (viii) SDCL, as amended, 2021 Revision, Title 34A, Environmental Protection: Chapter 34A-6, Solid Waste Disposal, section 34A-6-1.3(17); Chapter 34A-10, Remedies for Protection of Environment, sections 34A-10-1, 34A-10-2, 34A-10-2.5, 34A-10-5, 34A-10-11, 34A-10-14 and 34A-10-16, Chapter 34A-11, Hazardous Waste Management, sections 34A-11-1, 
                            <PRTPAGE P="8546"/>
                            34A-11-2 through 34A-11-4, 34A-11-5, 34A-11-8 through 34A-11-12, 34A-11-13 through 34A-11-16, 34A-11-17 through 34A-11-19, 34A-11-21 and 34A-11-22; Chapter 34A-12, Regulated Substance Discharges, sections 34A-12-1(8), 34A-12-4, 34A-12-6, 34A-12-8 through 34A-12-13, 34A-12-13.1 and 34A-12-14.
                        </P>
                        <P>(ix) SDCL, as amended, 2021 Revision, Title 37, Trade Regulation, Chapter 37-29, Uniform Trade Secrets Act, section 37-29-1(4).</P>
                        <P>(x) Administrative Rules of South Dakota (ARSD), Article 74:08, Administrative Fees, effective April 19, 2021: Chapter 74:08:01, Fees for Records Reproduction, sections 74:08:01:01, 74:08:01:03, 74:08:01:04, 74:08:01:05.</P>
                        <P>
                            (3) 
                            <E T="03">Related legal provisions.</E>
                             The following statutory provisions are broader in scope than the Federal program, are not part of the authorized program, are not incorporated by reference, and are not federally enforceable:
                        </P>
                        <P>(i) SDCL, as amended, 2021 Revision, Title 34A, Environmental Protection, Chapter 34A-11, Hazardous Waste Management, sections 34A-11-12.1, 34A-11-16.1, 34A-11-25 and 34A-11-26.</P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (4) 
                            <E T="03">Unauthorized State amendments.</E>
                             South Dakota has adopted but is not authorized for the following Federal final rules:
                        </P>
                        <P>
                            (i) Hazardous Waste Management System; User Fees for the Electronic Waste Manifest System and Amendments to Manifest Regulations (Non-HSWA), published in the 
                            <E T="04">Federal Register</E>
                             of 1/3/18.
                        </P>
                        <P>
                            (ii) Management Standards for Hazardous Waste Pharmaceuticals and Amendment to the P075 Listing for Nicotine (HSWA/Non-HSWA), published in the 
                            <E T="04">Federal Register</E>
                             of 2/22/19.
                        </P>
                        <P>(iii) Those Federal rules written under RCRA provisions that predate HSWA (non-HSWA) which the State has adopted, but for which it is not authorized, are not federally enforceable. In contrast, EPA will continue to enforce the Federal HSWA standards for which South Dakota is not authorized until the State receives specific authorization from EPA.</P>
                        <P>
                            (5) 
                            <E T="03">Memorandum of Agreement.</E>
                             The Memorandum of Agreement between EPA Region 8 and the State of South Dakota, signed by the Secretary of the South Dakota Department of Agriculture and Natural Resources Secretary on March 20, 2023, and by the EPA Region 8 Regional Administrator on March 10, 2023, although not incorporated by reference, is referenced as part of the authorized hazardous waste management program under subtitle C of RCRA, 42 U.S.C. 6921 
                            <E T="03">et seq.</E>
                        </P>
                        <P>
                            (6) 
                            <E T="03">Statement of legal authority.</E>
                             “Attorney General's Statement for Final Authorization”, signed by the Attorney General of South Dakota on May 24, 1984, and revisions, supplements and addenda to that Statement dated January 14, 1991, September 11, 1992, September 25, 1992, April 1, 1993, September 24, 1993, December 29, 1994, September 5, 1995, October 23, 1997, October 27, 1997, October 28, 1997, November 5, 1999, June 26, 2000, June 18, 2002, October 19, 2004, May 11, 2009, May 5, 2015, and November 29, 2021, although not incorporated by reference, are referenced as part of the authorized hazardous waste management program under subtitle C of RCRA, 42 U.S.C. 6921 
                            <E T="03">et seq.</E>
                        </P>
                        <P>
                            (7) 
                            <E T="03">Program Description.</E>
                             The Program Description and any other materials submitted as supplements thereto, although not incorporated by reference, are referenced as part of the authorized hazardous waste management program under subtitle C of RCRA, 42 U.S.C. 6921 
                            <E T="03">et seq.</E>
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="40" PART="272">
                    <AMDPAR>3. Amend appendix A to part 272 by revising the listing for “South Dakota” to read as follows:</AMDPAR>
                    <HD SOURCE="HD1">Appendix A to Part 272—State Requirements</HD>
                    <EXTRACT>
                        <STARS/>
                        <HD SOURCE="HD1">South Dakota</HD>
                        <P>The regulatory provisions include:</P>
                        <P>Administrative Rules of South Dakota (ARSD), Article 74:28, Hazardous Waste, as amended effective April 19, 2021, adopting by reference the Federal regulations as of July 1, 2018, and 83 FR 61552 (November 30, 2018).</P>
                        <P>Sections 74:28:21:01 (except the reference to “260.4 and 260.5” at 74:28:21:01(3)(b)(xii), and (14)(f)), 74:28:21:02, 74:28:21:03, 74:28:22:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)”), 74:28:23:01, 74:28:24:01, 74:28:25:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)”), 74:28:25:02 through 74:28:25:05, 74:28:26:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)” in the introductory paragraph), 74:28:27:01 (except the phrase “; 84 FR 36, 5938-5950 (February 22, 2019)” in the introductory paragraph), 74:28:28:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)”), 74:28:28:02 through 74:28:28:05, 74:28:29:01, 74:28:30:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)”) and 74:28:33:01 (except the phrase “; and 84 FR 36, 5938-5950 (February 22, 2019)”); Article 74:36, Air Pollution Control Program, section 74:36:11:01.</P>
                        <P>Copies of the South Dakota regulations that are incorporated by reference are available from South Dakota Legislative Research Council, 3rd Floor, State Capitol, 500 East Capitol Avenue, Pierre, SD 57501, (Phone: 605-773-3251).</P>
                        <STARS/>
                    </EXTRACT>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02310 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <CFR>45 CFR Parts 170 and 171</CFR>
                <RIN>RIN 0955-AA03</RIN>
                <SUBJECT>Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        This document corrects technical and typographical errors in the final rule entitled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” that was published in the 
                        <E T="04">Federal Register</E>
                         on January 9, 2024, and has a stated effective of February 8, 2024.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>As of February 8, 2024 the effective date of the final rule published on January 9, 2024 (89 FR 1192, FR 2023-28857), is corrected to March 11, 2024. The corrections in this document are effective on March 11, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Kate Tipping, Office of Policy, National Coordinator for Health Information Technology, 202-690-7151.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    In 
                    <E T="04">Federal Register</E>
                     document 2023-28857 (89 FR 1192) final rule entitled “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (HTI-1) (hereinafter referred to as the HTI-1 Final Rule), we identified certain technical and typographical errors following publication in the 
                    <E T="04">Federal Register</E>
                     on January 9, 2024. We summarize and correct these errors in the “Summary of Errors” and “Corrections of Errors” sections below.
                    <PRTPAGE P="8547"/>
                </P>
                <HD SOURCE="HD1">II. Summary of Errors</HD>
                <HD SOURCE="HD2">A. Preamble Errors—DATES Section—Effective Dates of the Rule</HD>
                <P>
                    On page 1192, first column, bottom of the page, we erroneously included an effective date of 30 days after publication of the final rule in the 
                    <E T="04">Federal Register</E>
                    , when it should have been 60 days after publication of the final rule in the 
                    <E T="04">Federal Register</E>
                    . The Congressional Review Act (CRA) requires a 60-day delay in the effective date of a major rule from the date of publication in the 
                    <E T="04">Federal Register</E>
                     or receipt of the rule by Congress, whichever is later (5 U.S.C. 801(a)(3)(A)). The rule was published in the 
                    <E T="04">Federal Register</E>
                     on January 9, 2024, and it has a stated effective date of February 8, 2024 (89 FR 1192). The 
                    <E T="03">Congressional Record</E>
                     reflects that House and Senate received the HTI-1 Final Rule on January 10, 2024 (
                    <E T="03">See</E>
                     170 Cong. Rec. H105 (Jan. 11, 2024). Accordingly, we are correcting the effective date to March 11, 2024.
                </P>
                <P>Also on page 1192, first column, bottom of page, the incorporation by reference approval date should be the effective date of the final rule. The HTI-1 Final Rule stated that the incorporation by reference approval date was February 8, 2024 (89 FR 1192). Because we inadvertently included an erroneous effective date, the incorporation by reference approval date must also be corrected to March 11, 2024.</P>
                <HD SOURCE="HD2">B. Preamble Errors—Part 171</HD>
                <HD SOURCE="HD3">1. Infeasibility Exception—Third Party Seeking Modification Use</HD>
                <P>On page 1376, third column, middle of the page, we transposed the numbers and added an extra zero in a reference to the Code of Federal Regulations (CFR). We inadvertently added 54 CFR part 1600. We included the correct cross-reference to the regulatory text in a parenthetical. However, the reference to 54 CFR part 1600 should read “45 CFR part 160.”</P>
                <HD SOURCE="HD2">C. Regulation Text Errors—Part 170—Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology</HD>
                <HD SOURCE="HD3">1. ONC Certification Criteria for Health IT</HD>
                <P>
                    On page 1429, third column, top of page, we inadvertently omitted amendatory text for § 170.315. Within amendatory instruction 9 for § 170.315, sub-instructions c. and f., we neglected to specify “introductory text” for three references. Within sub-instruction c., paragraph (b)(2)(iii)(D) should read “(b)(2)(iii)(D) introductory text” and the reference to paragraph (b)(3) should read “(b)(3)(ii)(A) introductory text.” Within sub-instruction f., paragraphs (e)(1)(i)(B)(
                    <E T="03">1</E>
                    ) and (2) should read “(e)(1)(i)(B)(
                    <E T="03">1</E>
                    ) and (
                    <E T="03">2)</E>
                     introductory text.” Also on page 1429, third column, top of page, we inadvertently included an incorrect reference and omitted an italicization in sub-instruction h. The reference to paragraphs (g)(10)(v)(A)(
                    <E T="03">1</E>
                    )(i) and (
                    <E T="03">ii</E>
                    ), (g)(10)(v)(A)(
                    <E T="03">1</E>
                    )(B), (g)(10)(v)(A)(
                    <E T="03">2</E>
                    )(
                    <E T="03">i</E>
                    ) and (
                    <E T="03">ii</E>
                    ) should read “(g)(10)(v)(A)(
                    <E T="03">1</E>
                    )(
                    <E T="03">i</E>
                    ) and (
                    <E T="03">ii</E>
                    ), (g)(10)(v)(A)(
                    <E T="03">2</E>
                    )(
                    <E T="03">i</E>
                    ) and (
                    <E T="03">ii</E>
                    ), (g)(10)(v)(A)(B)”.
                </P>
                <HD SOURCE="HD3">a. Transitions of Care</HD>
                <P>
                    On page 1430, middle column, top half of the page, we inadvertently referenced §  170.207(n)(2) in § 170.315(b)(1)(iii)(G)(3), Sex constraint. In the HTI-1 Proposed Rule (88 FR 23766), we proposed to remove the requirement in § 170.315(a)(5)(i)(C) and § 170.315(b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ) to code Sex according to the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1). We proposed instead to permit coding according to either the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1) until December 31, 2025, or in accordance with the standard in proposed § 170.207(n)(2) (89 FR 1220).
                </P>
                <P>
                    In the HTI-1 Proposed Rule, we also proposed to update § 170.315(c)(4)(iii)(G) introductory text and (b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ) to reference § 170.207(n)(2) (89 FR 1225). In the HTI-1 Final Rule, we noted that, in the HTI-1 Proposed Rule regulation text in § 170.315(b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ), we inadvertently included a reference to § 170.213 (88 FR 23909) instead of including § 170.207(n)(2) as discussed in our proposal (88 FR 23821). We finalized § 170.315(b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ) without the proposed reference to § 170.213. We stated that we finalized § 170.315(b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ) to include a reference to § 170.207(n)(2) to correct this error and to reference the most recent version of SNOMED CT U.S. Edition available at the time of this rule (89 FR 1225). In the HTI-1 Final Rule, we also finalized our proposal that the adoption of the code sets referenced in §  170.207(n)(1) will expire on January 1, 2026, and that health IT developers can continue to use the specific codes in the current terminology standard through December 31, 2025, in order to provide adequate time for Health IT Modules certified to particular certification criteria to transition to the updated terminology standards (89 FR 1198). In the HTI-1 Final Rule, we finalized the timelines for the respective standards updates as proposed and stated our intent to allow the use of the standards for the criterion consistent with those dates (89 FR 1225). We further stated that developers of certified health IT with Health IT Modules certified to criteria that reference §  170.207(n)(1) would be required to update those Health IT Modules to §  170.207(n)(2) and provide them to customers by January 1, 2026 (89 FR 1298). Therefore, in this final rule correction we have added a reference to § 170.207(n)(1) up to and including December 31, 2025, in § 170.315(b)(1)(iii)(G)(
                    <E T="03">3</E>
                    ). Referencing § 170.207(n)(1) in this manner is consistent with the rationale that Sex be coded according to the adopted value sets in § 170.207(n)(1) until January 1, 2026; or coded according to the adopted standards in § 170.207(n)(2), and consistent with what we proposed (88 FR 23766) and intended to finalize.
                </P>
                <HD SOURCE="HD3">b. Electronic Prescribing</HD>
                <P>On page 1430, third column, top of page, in § 170.315(b)(3) we also inadvertently omitted five asterisks after paragraph (b)(3)(ii)(A). The text in (b)(3) should remain unchanged except for the revisions in (b)(3)(ii)(A).</P>
                <HD SOURCE="HD3">2. Real World Testing</HD>
                <P>On page 1434, first column, middle of page, in amendatory instruction 12 for § 170.405, we neglected to specify “introductory text” after paragraph (b)(2)(ii). The correct reference should say “(b)(2)(ii) introductory text.”</P>
                <HD SOURCE="HD3">3. Discontinuation of Year Themed Editions</HD>
                <P>
                    In the HTI-1 Final Rule, we finalized the discontinuation of year themed editions for ONC Certification Criteria for Health IT and renamed all certification criteria within the Program simply as “ONC Certification Criteria for Health IT” (89 FR 1206). In the HTI-1 Proposed Rule (88 FR 23912, 23914), we proposed to remove and replace references to the 2015 Edition in §§ 170.406(a)(5) and 170.550(h)(1). In the HTI-1 Final Rule, we finalized the removal of year themed Editions as proposed and stated that we “replaced references to the `2015 Edition' in §§  170.102, 170.405, 170.406, 170.523, 170.524, and 170.550 (89 FR 1207). However, when removing the references to the 2015 Edition in the regulation text, we neglected to remove and replace the reference to the 2015 Edition 
                    <PRTPAGE P="8548"/>
                    in §§ 170.406(a)(5) and 170.550(h)(1). Because year themed editions have been discontinued, including the 2015 Edition, and because we proposed to remove and replace these references and stated that we finalized as proposed, in this final rule correction we have corrected §§ 170.406(a)(5) and 170.550(h)(1) to replace the references to the 2015 Edition with references to ONC Certification Criteria for Health IT.
                </P>
                <HD SOURCE="HD1">III. Waiver of Proposed Rulemaking, Comment Period, and Delay in Effective Date</HD>
                <P>
                    Under 5 U.S.C. 553(b) of the Administrative Procedure Act (APA), the agency is required to publish a notice of the proposed rulemaking in the 
                    <E T="04">Federal Register</E>
                     before the provisions of a rule take effect. In addition, section 553(d) of the APA mandates a 30-day delay in effective date after issuance or publication of a rule. Sections 553(b)(B) and 553(d)(3) of the APA provide for exceptions from the notice and comment and delay in effective date requirements. Section 553(b)(B) of the APA authorizes an agency to dispense with normal rulemaking requirements for good cause if the agency makes a finding that the notice and comment process are impracticable, unnecessary, or contrary to the public interest. In addition, section 553(d)(3) of the APA allows the agency to avoid the 30-day delay in effective date where such delay is contrary to the public interest and an agency includes a statement of support.
                </P>
                <P>We believe this final rule correction does not constitute a rule that would be subject to the APA notice and comment or delayed effective date requirements. This document corrects technical and typographical errors in the preamble and regulation text of the HTI-1 Final Rule, but does not make substantive changes to the policies that were adopted in the HTI-1 Final Rule. As a result, this final rule correction is intended to ensure that the information in the HTI-1 Final Rule accurately reflects the policies adopted in that document.</P>
                <P>In addition, even if this were a rule to which the notice and comment procedures and delayed effective date requirements applied, we find that there is good cause to waive such procedures and requirements. Undertaking further notice and comment procedures to incorporate the corrections in this document into the HTI-1 Final Rule would be contrary to the public interest because these corrections ensure the HTI-1 Final Rule complies with the CRA and do not change the policies laid out in the HTI-1 Final Rule. This final rule correction is intended solely to ensure that the HTI-1 Final Rule accurately reflects applicable law and the policies finalized in the HTI-1 Final Rule. Therefore, we believe we have good cause to waive the notice and comment and effective date requirements.</P>
                <HD SOURCE="HD1">IV. Corrections of Errors</HD>
                <P>
                    In FR Doc. 2023-28857 appearing on page 1192 in the 
                    <E T="04">Federal Register</E>
                     of January 9, 2024, for the reasons stated above, the Office of the Secretary corrects the following:
                </P>
                <AMDPAR>
                    1. On page 1192, first column, bottom of the page, correct the 
                    <E T="02">DATES</E>
                     section to read as follows:
                </AMDPAR>
                <FP>
                    <E T="02">DATES:</E>
                      
                    <E T="03">Effective date:</E>
                     This final rule is effective on March 11, 2024.
                </FP>
                <P>
                    <E T="03">Incorporation by reference:</E>
                     The incorporation by reference of certain publications listed in the rule was approved by the Director of the Federal Register as of March 11, 2024.
                </P>
                <REGTEXT TITLE="45" PART="160">
                    <AMDPAR>2. On page 1376, third column, middle of the page, correct the reference to “54 CFR part 1600” to read “45 CFR part 160.”</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>3. On page 1429, in the third column, instructions 9.c, 9.f and 9.h to section § 170.315 are corrected to read as follows:</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>9. Amend § 170.315 by:</AMDPAR>
                    <STARS/>
                    <AMDPAR>
                        c. Revising paragraphs (a)(12), (b)(1)(iii)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ); (b)(1)(iii)(B)(
                        <E T="03">2</E>
                        ), (b)(1)(iii)(G) introductory text, (b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ), (b)(2)(i) and (ii), (b)(2)(iii)(D) introductory text, and (b)(2)(iv), (b)(3)(ii)(A) introductory text, (b)(6)(ii)(B)(
                        <E T="03">2</E>
                        ), and (b)(9)(ii);
                    </AMDPAR>
                    <STARS/>
                    <AMDPAR>
                        f. Revising paragraphs (e)(1)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), and (e)(1)(i)(B)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) introductory text, and adding paragraph (e)(1)(iii);
                    </AMDPAR>
                    <STARS/>
                    <AMDPAR>
                        h. Revising paragraphs (g)(3) introductory text, (g)(6)(i)(A) and (B), (g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), (g)(10)(i)(A) and (B), (g)(10)(ii)(A) and (B), (g)(10)(iv)(A) and (B), (g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ), (g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ), (g)(10)(v)(B), and (g)(10)(vi) and (vii).
                    </AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>
                        4. On page 1430, starting in the second column, in amendatory instruction 9, in § 170.315 correct paragraphs (b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ), (b)(3)(ii)(A) introductory text, (g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ), (g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ), and (g)(10)(v)(B) to read as follows:
                    </AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.315 </SECTNO>
                        <SUBJECT>[Corrected]</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) * * *</P>
                        <P>(iii) * * *</P>
                        <P>(G) * * *</P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Sex Constraint:</E>
                             Represent sex with the standard adopted in § 170.207(n)(1) up to and including December 31, 2025; or with the standard adopted in § 170.207(n)(2).
                        </P>
                        <STARS/>
                        <P>(3) * * *</P>
                        <P>(ii) * * *</P>
                        <P>(A) Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(1) as follows:</P>
                        <STARS/>
                        <P>(g) * * *</P>
                        <P>(10) * * *</P>
                        <P>(v) * * *</P>
                        <P>(A) * * *</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) * * *
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) A Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c).
                        </P>
                        <STARS/>
                        <P>
                            (
                            <E T="03">2</E>
                            ) * * *
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(c) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c).
                        </P>
                        <P>(B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(d) and the application must be issued a valid access token.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 170.405 </SECTNO>
                    <SUBJECT>[Corrected]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>5. On page 1434, first column, middle of page, in amendatory instruction 12 for § 170.405 correct instruction 12.a to read as “a. Revising paragraphs (a) and (b)(2)(ii) introductory text; and”</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <PRTPAGE P="8549"/>
                    <AMDPAR>6. Starting on page 1434, in the second column, redesignate instructions 13 through 22 as instructions 14 through 23.</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>7. On page 1434, in the second column, add a new instruction 13 and accompanying regulatory text to read as follows:</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>13. Amend § 170.406 by revising paragraph (a)(5) to read:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.406 </SECTNO>
                        <SUBJECT>Attestations</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(5) Section 170.405 if a health IT developer has a Health IT Module(s) certified to any one or more ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h).</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>8. On page 1435, starting in the second column, correct newly redesignated instruction 17 and the accompanying regulatory text to read as follows:</AMDPAR>
                </REGTEXT>
                <REGTEXT TITLE="45" PART="170">
                    <AMDPAR>17. Amend § 170.550 by revising paragraphs (g) introductory text, (h)(1), and (m) introductory text to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.550 </SECTNO>
                        <SUBJECT>Health IT Module certification.</SUBJECT>
                        <STARS/>
                        <P>
                            (g) 
                            <E T="03">Health IT Module dependent criteria.</E>
                             When certifying a Health IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB must certify the Health IT Module in accordance with the certification criteria at:
                        </P>
                        <STARS/>
                        <P>(h) * * *</P>
                        <P>
                            (1) 
                            <E T="03">General rule.</E>
                             When certifying a Health IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB can only issue a certification to a Health IT Module if the privacy and security certification criteria in paragraphs (h)(3)(i) through (ix) of this section have also been met (and are included within the scope of the certification).
                        </P>
                        <STARS/>
                        <P>
                            (m) 
                            <E T="03">Time-limited certification and certification status for certain ONC Certification Criteria for Health IT.</E>
                             An ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for:
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <NAME>Elizabeth J. Gramling,</NAME>
                    <TITLE>Executive Secretary to the Department, Department of Health and Human Services.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02519 Filed 2-6-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4150-45-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Part 64</CFR>
                <DEPDOC>[CG Docket Nos. 03-123, 10-51, 13-24 and WC Docket No. 12-375; FCC 22-51; FCC 22-76; FR ID 201005]</DEPDOC>
                <SUBJECT>VRS and IP CTS—Commencement of Pending User Registration; Rates for Interstate Inmate Calling Services; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Technical amendments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Federal Communications Commission (Commission) corrects the effective date for rules published in a document in the 
                        <E T="04">Federal Register</E>
                         on December 21, 2023. The document incorrectly announced an effective date for certain amendments to the Commission's regulations.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        The amendments to § 64.6060(a)(5) through (7) in amendatory instruction 2 are effective February 8, 2024. The amendments to § 64.6060(a)(5) through (7) in amendatory instruction 3 are delayed indefinitely. The Commission will publish a document in the 
                        <E T="04">Federal Register</E>
                         announcing the effective date.
                    </P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Michael Scott, Disability Rights Office, Consumer and Governmental Affairs Bureau, at (202) 418-1264, or email: 
                        <E T="03">Michael.Scott@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This document corrects the effective date for amendments to § 64.6060(a)(5) through (7), published at 87 FR 75496, December 9, 2022, which triggered the codification of those amendments on December 21, 2023. The document corrects § 64.6060(a)(5) through (7) (amendatory instruction 2) to revert the rule to the prior text. The document publishes amendments to § 64.6060(a)(5) through (7) (amendatory instruction 3) that are delayed pending Office of Management and Budget (OMB) approval of the information requirements contained in the Commission's Report and Order, FCC 22-76, published at 87 FR 75496, December 9, 2022. The Commission will publish a document in the 
                    <E T="04">Federal Register</E>
                     announcing the effective date for the delayed amendments.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 47 CFR Part 64</HD>
                    <P>Individuals with disabilities, Telecommunications, Telephone.</P>
                </LSTSUB>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Marlene Dortch,</NAME>
                    <TITLE>Secretary, Office of the Secretary.</TITLE>
                </SIG>
                <P>Accordingly, 47 CFR part 64 is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 64—MISCELLANEOUS RULES RELATING TO COMMON CARRIERS</HD>
                </PART>
                <REGTEXT TITLE="47" PART="64">
                    <AMDPAR>1. The authority citation for part 64 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>47 U.S.C. 151, 152, 154, 201, 202, 217, 218, 220, 222, 225, 226, 227, 227b, 228, 251(a), 251(e), 254(k), 255, 262, 276, 301, 303, 316, 345, 403(b)(2)(B), (c), 616, 620, 716, 1401-1473, unless otherwise noted; Div. P, sec. 503, Pub. L. 115-141, 132 Stat. 348, 1091; sec. 5, Pub. L. 117-223, 136 Stat 2280, 2285-88 (47 U.S.C. 345 note).</P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart FF—Inmate Calling Services</HD>
                </SUBPART>
                <REGTEXT TITLE="47" PART="64">
                    <AMDPAR>2. Amend § 64.6060 by revising paragraphs (a)(5) through (7) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 64.6060 </SECTNO>
                        <SUBJECT>Annual reporting and certification requirement.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(5) The number of TTY-based Inmate Calling Services calls provided per facility during the reporting period;</P>
                        <P>(6) The number of dropped calls the reporting Provider experienced with TTY-based calls; and</P>
                        <P>
                            (7) The number of complaints that the reporting Provider received related to 
                            <E T="03">e.g.,</E>
                             dropped calls, poor call quality and the number of incidences of each by TTY and TRS users.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="64">
                    <AMDPAR>3. Delayed indefinitely, further amend § 64.6060 by revising paragraphs (a)(5) through (7) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 64.6060 </SECTNO>
                        <SUBJECT>Annual reporting and certification requirement.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(5) For each facility served, the kinds of TRS that may be accessed from the facility;</P>
                        <P>(6) For each facility served, the number of calls completed during the reporting period in each of the following categories:</P>
                        <P>(i) TTY-to-TTY calls;</P>
                        <P>(ii) Point-to-point video calls placed or received by ASL users as those terms are defined in § 64.601(a); and</P>
                        <P>(iii) TRS calls, broken down by each form of TRS that can be accessed from the facility; and</P>
                        <P>(7) For each facility served, the number of complaints that the reporting Provider received in each of the categories set forth in paragraph (a)(6) of this section.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02384 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="8550"/>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Transportation Security Administration</SUBAGY>
                <CFR>49 CFR Part 1548</CFR>
                <DEPDOC>[Docket No. TSA-2020-0002]</DEPDOC>
                <RIN>RIN 1652-AA72</RIN>
                <SUBJECT>Frequency of Renewal Cycle for Indirect Air Carrier Security Programs</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Transportation Security Administration, Department of Homeland Security (DHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Transportation Security Administration (TSA) is modifying its regulations to reduce the frequency of renewal applications by indirect air carriers (IACs). Rather than requiring these entities to submit an application to renew their security program each year, TSA now requires renewal once every 3 years. This modification reduces the burden of compliance without a negative impact on security.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective March 11, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Angel Rodriguez, telephone 1-571-227-2108; email 
                        <E T="03">angel.l.rodriguez@tsa.dhs.gov;</E>
                         6595 Springfield Center Drive, Springfield, VA 20598-6003.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Availability of Rulemaking Document</HD>
                <P>
                    You can find an electronic copy of this rule using the internet by accessing the Government Publishing Office's web page at 
                    <E T="03">https://www.govinfo.gov/app/collection/FR/</E>
                     to view the daily published 
                    <E T="04">Federal Register</E>
                     edition or accessing the Office of the Federal Register's web page at 
                    <E T="03">https://www.federalregister.gov.</E>
                     Copies are also available by contacting the individual identified for “General Questions” in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section. Make sure to identify the docket number of this rulemaking.
                </P>
                <HD SOURCE="HD1">Small Entity Inquiries</HD>
                <P>
                    The Small Business Regulatory Enforcement Fairness Act (SBREFA) of 1996 requires TSA to comply with small entity requests for information and advice about compliance with statutes and regulations within TSA's jurisdiction. Any small entity that has a question regarding this document may contact the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section. Persons can obtain further information regarding SBREFA on the Small Business Administration's web page at 
                    <E T="03">https://www.sba.gov/category/advocacy-navigation-structure/regulatory-policy/regulatory-flexibility-act/sbrefa.</E>
                </P>
                <HD SOURCE="HD1">Abbreviations and Terms Used in This Document</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CCSF—Certified Cargo Screening Facility</FP>
                    <FP SOURCE="FP-1">CEQ—Council on Environmental Quality</FP>
                    <FP SOURCE="FP-1">DHS—Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">DOT—Department of Transportation</FP>
                    <FP SOURCE="FP-1">E.O.—Executive Order</FP>
                    <FP SOURCE="FP-1">FOIA—Freedom of Information Act</FP>
                    <FP SOURCE="FP-1">IAC—Indirect Air Carrier</FP>
                    <FP SOURCE="FP-1">IACSSP—Indirect Air Carrier Standard Security Program</FP>
                    <FP SOURCE="FP-1">NEPA—National Environmental Policy Act</FP>
                    <FP SOURCE="FP-1">OMB—Office of Management and Budget</FP>
                    <FP SOURCE="FP-1">PRA—Paperwork Reduction Act of 1995</FP>
                    <FP SOURCE="FP-1">SBREFA—Small Business Regulatory Enforcement Fairness Act of 1996</FP>
                    <FP SOURCE="FP-1">SSI—Sensitive Security Information</FP>
                    <FP SOURCE="FP-1">TSA—Transportation Security Administration</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Executive Summary</HD>
                <HD SOURCE="HD2">A. Purpose of the Regulation</HD>
                <P>The Indirect Air Carrier (IAC), sometimes called a freight forwarder, acts as an intermediary between a shipper of air cargo and an air carrier by receiving and consolidating cargo from one or more shippers for transport on one or more aircraft flights. IACs are a critical component of the secure air cargo supply chain in the United States, helping to ensure the safe, timely, and efficient movement of goods every day. Approximately 3,800 IACs are operating in the United States and registered with TSA, ranging from sole proprietors working out of their homes to large corporations. Currently, TSA's regulations require IACs to renew their registration each year.</P>
                <P>TSA is modifying 49 CFR 1548.7 to reduce the frequency at which IACs must renew their registration from annual to once every 3 years. This modification reduces the burden of compliance by reducing the time and effort an IAC must devote to renewing their registration, permitting them to focus on other operational and business priorities. TSA has determined that the change will not have a negative impact on aviation security.</P>
                <HD SOURCE="HD2">B. Summary of Major Provisions</HD>
                <P>This final rule makes limited changes to 49 CFR 1548.7, which are necessary to change the regulatory requirement for the IAC security program-renewal from 1 year to 3 years. Table 1 identifies each change.</P>
                <HD SOURCE="HD2">C. Costs and Benefits</HD>
                <P>TSA has determined this modification reduces the cost of compliance without any negative impacts on security. As described in the notice of proposed rulemaking (NPRM) (87 FR 79264, December 27, 2022) and as noted below, TSA estimates that, over 10 years, cost savings aggregate to $7.8 million undiscounted, $6.6 million discounted at 3 percent, and $5.4 million discounted at 7 percent. This final rule would realize an annualized $0.8 million cost savings discounted at 7 percent over 10 years.</P>
                <HD SOURCE="HD1">II. General Discussion of the Rulemaking</HD>
                <HD SOURCE="HD2">A. Background</HD>
                <P>
                    To ensure the security of the air cargo system, TSA imposes security requirements on IACs in 49 CFR part 1548. Through these regulations, TSA ensures “IACs are held accountable for securing the goods entrusted to them throughout those legs of the supply chain for which they are responsible.” 
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Proposed Rule, Air Cargo Security Requirements, 69 FR 65257, 65269 (Nov. 10, 2004).
                    </P>
                </FTNT>
                <P>Under 49 CFR 1548.5, each IAC must adopt and carry out the IAC Standard Security Program (IACSSP). Persons interested in becoming IACs are vetted by TSA and are required to implement security requirements in the IACSSP. These requirements are intended to ensure security during the period between when a package leaves a shipper and when it is presented to the aircraft operators. IACs must also ensure their employees understand and are trained to implement their security responsibilities.</P>
                <P>Current 49 CFR 1548.7(b) presents the processes an IAC must follow annually to seek renewed approval from TSA to operate under the IACSSP. In general, annual renewal is a continuation of current practices and security measures in the IACSSP, including any TSA-approved amendments issued under 49 CFR 1548.7(c), (d), and/or (e). IACs must submit the renewal request to TSA at least 30 calendar days before expiration of the IACSSP, as well as other standards for the submission.</P>
                <P>
                    Since 2006, TSA has required IACs to renew their registration each year. Since the annual renewal requirement was imposed in 2006, TSA has determined that it is unnecessary to continue requiring annual renewal and that the program could be renewed once every 3 years without having a negative impact on security. As discussed below, this determination is based on two key factors: (1) TSA's inspection processes and priorities for IACs negate the need for annual renewals, and (2) the triennial renewal requirement for other TSA air cargo programs that have proven to be effective and secure.
                    <PRTPAGE P="8551"/>
                </P>
                <P>
                    TSA published an NPRM on December 27, 2022,
                    <SU>2</SU>
                    <FTREF/>
                     proposing to change the renewal period, and requested comments from the public to be submitted by February 27, 2023. TSA received two comments, both from interested industry associations.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         87 FR 79264 (Dec. 27, 2022).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Summary of Comments</HD>
                <P>
                    TSA received two comments, both from interested industry associations. One trade association representing indirect air carriers and aircraft operators expressed general support for the rule, and expressed the belief that the rule would not negatively impact security.
                    <SU>3</SU>
                    <FTREF/>
                     Another trade association representing airline pilots recommended that TSA not move forward with the rulemaking.
                    <SU>4</SU>
                    <FTREF/>
                     The association for the airline pilots stated: (1) TSA should not reduce oversight in pursuit of economic relief, which could reduce opportunities to discover evolving security threats; (2) TSA's estimated burden of 4 hours to complete annual certification is not a meaningful burden on industry; (3) the high turnover rate among IAC staff requires TSA audits and training verification on an annual basis at a minimum; and (4) if TSA's process for revalidating IACs is tied to their security program renewals, the shift to a 3-year renewal cycle would create an unnecessary security risk and TSA should assess IACs for security risks on an annual basis, or more frequently.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">https://www.regulations.gov/docket/TSA-2020-0002/comments,</E>
                         TSA-2020-0002-0002.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">https://www.regulations.gov/docket/TSA-2020-0002/comments,</E>
                         TSA-2020-0002-0003.
                    </P>
                </FTNT>
                <P>
                    <E T="03">TSA Response:</E>
                     Following review of the issues raised by the airlines pilots' association, TSA has determined that the commenter provided no new information to counter TSA's previous determination on the benefits and need for this rulemaking. First, TSA is not sacrificing security in order to obtain economic benefits. These limited changes to the IAC regulation are consistent with 49 U.S.C. 114(l)(3), which requires TSA to consider the costs of any proposed regulation relative to its security benefit. In addition, Executive Order (E.O.) 13563 of January 18, 2011 (Improving Regulation and Regulatory Review), requires agencies to periodically review existing regulations to identify requirements that “may be outmoded, ineffective, insufficient, or excessively burdensome, and to modify, streamline, expand, or repeal them in accordance with what has been learned.” 
                    <SU>5</SU>
                    <FTREF/>
                     Before proposing this change, TSA conducted a risk analysis and determined that the revision would not have a negative impact on security due to other compensating procedures. This final rule provides an overall reduction in the burden of compliance without negatively affecting security.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         sec. 6 of E.O. 13563.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         87 FR 79265.
                    </P>
                </FTNT>
                <P>
                    Second, the costs of compliance with the annual renewal requirement may be relatively small for each IAC, but TSA estimates that over 10 years the cost savings aggregate to $7.8 million undiscounted, $6.6 million discounted at 3 percent, and $5.4 million discounted at 7 percent. The rule would realize annualized savings of $0.8 million in 2020 dollars.
                    <SU>7</SU>
                    <FTREF/>
                     These cost savings accrue for both the industry and TSA. Reducing the administrative burden on TSA staff of reviewing annual renewal applications allows TSA to focus additional resources and staff effort on the highest air cargo security priorities.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         87 FR 79266.
                    </P>
                </FTNT>
                <P>
                    Third, as noted in the NPRM, the transition from an annual security program certification to a 3-year security program certification renewal period does not mean that IACs will only be assessed or audited for compliance once every 3 years. As discussed in the NPRM and below, TSA has determined that a 3-year renewal cycle is effective, efficient, and secure when coupled with an appropriately staffed and resourced inspection and enforcement program.
                    <SU>8</SU>
                    <FTREF/>
                     TSA acknowledges the airline pilots association concern regarding turnover in the IAC industry, but an extension of the recertification period does not mean a reduction in regulatory inspections. This determination is supported by TSA's experience with other air cargo security regulations, specifically the Certified Cargo Screening Program (CCSP), and TSA believes it will be similarly effective with IACs.
                    <SU>9</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See id.</E>
                         for more discussion on this issue.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>Fourth, under this final rule, within any 3-year period, every IAC will be subject to at least one triennial comprehensive inspection, two targeted annual inspections in years when a comprehensive inspection is not conducted, and possible supplemental inspections whenever TSA's assessment of risk or evolving compliance posture indicate that additional inspections are warranted. TSA's process for inspecting and revalidating IACs is not tied to the annual renewal of IAC security programs because the inspection and revalidation schedules of TSA inspectors are managed separately from TSA's program renewal efforts. TSA implements a national inspection plan based on regular cycles, and conducts focused Special Emphasis Assessments and Special Emphasis Inspections whenever necessary. Further, TSA's local inspection plans augment the national plan with risk-based local inspection and revalidation schedules that consider regional threats, a specific IAC's past performance, and other factors.</P>
                <P>TSA's local field offices determine whether to conduct additional inspections of an individual IAC by assessing the results of prior compliance reviews in light of evolving and emerging threat information. TSA's local field offices may conduct more frequent inspections of IACs that have lower compliance rates, or otherwise present an elevated security risk. All IACs are subject to supplemental inspections if the local field office determines one is necessary.</P>
                <P>When TSA imposed the annual renewal requirement in 2006, TSA expected that the annual cycle of renewals would be the primary method to ensure the agency regularly reviewed each IAC and confirmed compliance with TSA security requirements. As described above, TSA now ensures compliance with the program through the nationwide schedule of regular annual inspections, Special Emphasis Assessments and Inspections, and additional inspections at the discretion of the local field office.</P>
                <P>An additional safeguard is provided by 49 CFR 1540.301, which allows TSA to withdraw approval of an IAC security program if TSA determines continued operation is contrary to security and the public interest. If TSA withdraws approval, an IAC must discontinue operation immediately, regardless of the renewal date of its program certification.</P>
                <P>
                    As TSA noted in the NPRM,
                    <SU>10</SU>
                    <FTREF/>
                     the triennial renewal requirement for other TSA air cargo programs have proven to be effective and secure. In addition to recognizing the effectiveness of its regular inspections to ensure compliance with the IAC program, TSA considered the requirements for the IAC program compared to other aviation security requirements, specifically requirements for the CCSP under 49 CFR part 1549. When TSA finalized the rule establishing the CCSP in 2011, TSA provided a 3-year renewal period for Certified Cargo Screening Facilities (CCSFs). Experience gained by more than a decade of implementing the CCSP validates that the triennial recertification cycle does not have a negative impact on security. The final rule does not change the actions that 
                    <PRTPAGE P="8552"/>
                    IACs must perform to recertify or the requirements they must meet to maintain approval to operate as an IAC; the final rule simply reduces the frequency with which they must recertify.
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         87 FR 79266.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Section-by-Section Analysis</HD>
                <P>After consideration of each comment and any relevant potential changes to the proposed rule, TSA is adopting the revisions as proposed in the NPRM. TSA has addressed all issues and concerns derived from these comments in the discussion below.</P>
                <P>Table 1 identifies each change made to 49 CFR 1548.7 as a result of this rulemaking.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,r150,r150">
                    <TTITLE>Table 1—Changes to 49 CFR 1548.7</TTITLE>
                    <BOXHD>
                        <CHED H="1">Section</CHED>
                        <CHED H="1">Prior text</CHED>
                        <CHED H="1">Revised text</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1548.7(a)(4)</ENT>
                        <ENT>Removing the words “one year after the month it was approved”</ENT>
                        <ENT>Adding in their place “3 years after the month it was approved, or until the program has been surrendered or withdrawn, whichever is earlier”.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1548.7(a)(5)</ENT>
                        <ENT/>
                        <ENT>In the introductory text, adding the words “or renewal” after the words “submitted during its initial”.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1548.7(b)(1)</ENT>
                        <ENT>Removing the words “at least 30 calendar days prior to the first day of the anniversary month of initial approval”</ENT>
                        <ENT>Adding in their place “at least 30 calendar days before the 36th month after the initial approval”.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1548.7(b)(4)</ENT>
                        <ENT>Removing the words “one year after the month it was renewed”</ENT>
                        <ENT>Adding in their place “3 years after the month it was renewed, or until the program has been surrendered or withdrawn, whichever is earlier”.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">III. Regulatory Analyses</HD>
                <P>TSA conducted a regulatory impact analysis (RIA) for the NPRM, posted in the docket for this rulemaking. As there were no comments related to the regulatory impact analysis in the NPRM, TSA has made no changes to the analysis in this final rule. TSA considered numerous statutes and executive orders related to rulemaking when developing this rule. The following summarizes TSA's analyses of the impact of the rulemaking as directed by these statutes or Executive orders.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <HD SOURCE="HD3">1. Background</HD>
                <P>
                    Under the requirements of E.O. 12866 of September 30, 1993 (Regulatory Planning and Review),
                    <SU>11</SU>
                    <FTREF/>
                     as amended by E.O. 14094 of April 6, 2023 (Modernizing Regulatory Review),
                    <SU>12</SU>
                    <FTREF/>
                     and E.O. 13563 of January 18, 2011 (Improving Regulation and Regulatory Review),
                    <SU>13</SU>
                    <FTREF/>
                     agencies must assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). These requirements were supplemented by E.O. 13563, which emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         Published at 58 FR 51735 (Oct. 4, 1993).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         Published at 88 FR 21879 (Apr. 6, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         Published at 76 FR 3821 (Jan. 21, 2011).
                    </P>
                </FTNT>
                <P>The Office of Management and Budget (OMB) has determined this rule is not a significant regulatory action under section 3(f) of E.O. 12866, as amended. Accordingly, OMB has not reviewed this rule.</P>
                <P>In conducting these analyses, TSA has certified that this rulemaking does not have a significant economic impact on a substantial number of small entities.</P>
                <P>The basis for this conclusion is set forth below.</P>
                <P>This final rule reduces regulatory costs by reducing the frequency that IACs must renew their security program certifications. This final rule reduces the frequency of annual IAC security program certifications to once every 3 years. This rule does not impose any incremental costs because regulated entities are already performing all actions required to obtain the certification in question. The expected outcome will be a minimal impact with positive net benefits.</P>
                <HD SOURCE="HD3">2. Estimated Cost Savings to Affected Entities</HD>
                <P>
                    The cost savings from this rule arise from extending the duration of IAC security programs approved by TSA from 1 year to 3 years. This change aligns the duration of the IAC security program with the CCSP.
                    <SU>14</SU>
                    <FTREF/>
                     Table 2 summarizes the change and impact from this action.
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         See 49 CFR 1549.7(a)(6). 
                        <E T="03">See</E>
                         also 
                        <E T="03">supra</E>
                         notes 8 and 10, and accompanying text.
                    </P>
                </FTNT>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r50,r150,r200">
                    <TTITLE>Table 2—Comparison of Current 49 CFR Part 1548 and the Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Current</CHED>
                        <CHED H="1">Final rule</CHED>
                        <CHED H="1">Impact</CHED>
                        <CHED H="1">Estimated cost savings</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Requires annual renewal of security program</ENT>
                        <ENT>Revises to renewal every 3 years</ENT>
                        <ENT>
                            (1) Aligns part 1548 renewal period with that of the TSA-approved Certified Cargo Screening Program, part 1549
                            <LI>(2) Provides cost savings to industry and TSA</LI>
                        </ENT>
                        <ENT>TSA estimates the annualized cost saving to industry and Federal government to be $0.8 million annualized at a 7 percent discount rate. Cost savings arise from time saved due to a less frequent security program renewal cycle.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>To estimate cost savings, TSA calculates the number of instances an IAC would resubmit a security program under the current annual requirement, and the number of instances that would be avoided under the final rule's 3-year requirement. TSA uses the difference in the number of resubmission instances between the current requirement and the final rule as the basis for the cost savings.</P>
                <P>
                    TSA uses historical data on the number of existing IACs to forecast the number of security programs submitted for certification over the 10-year period of analysis. TSA assumes that the regulatory change for less frequent 
                    <PRTPAGE P="8553"/>
                    recertification does not impact the annual number of forecasted active IAC certifications. Based on historical program data, TSA assumes the aggregate population of active and approved IACs under the baseline and the final rule decreases each year with more dropping out than entering. TSA calculates that the aggregate active population decreases at an annual rate of 1.61 percent 
                    <SU>15</SU>
                    <FTREF/>
                     and compounds this rate to estimate the aggregate active IAC population for the next 10 years, as displayed in column 
                    <E T="03">a</E>
                     of Table 3. The aggregate active population of IACs (column 
                    <E T="03">a</E>
                    ) also represents the number of security program submissions and resubmissions under the baseline annual renewal requirement.
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         Based on TSA data, there were 4,576 IACs in 2008 and 3,768 in 2020. TSA calculates a negative compound annual growth rate of 1.61% = (3,768 ÷ 4,576)
                        <E T="51">(1 ÷ (2020−2008))</E>
                        −1.
                    </P>
                </FTNT>
                <P>
                    TSA postulates that the number of newly approved IAC applications represents a proportion of the number of aggregate active IACs in the same year. This proportion has stabilized over the last 5 years at 5.41 percent. TSA applied this percentage to the forecasted aggregate number of active IACs during a year to estimate the number of newly approved IAC applications during the same year 
                    <SU>16</SU>
                    <FTREF/>
                     as displayed in column 
                    <E T="03">c</E>
                     of Table 3.
                </P>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         The number of aggregate active IACs is estimated using the previous year aggregate value and the negative growth rate. For instance, the year 0 (2022) aggregate number of active IACs of 3,648 is estimated applying the negative growth rate to the year−1 (2021) aggregate number of 3,707: 3,648 = 3,707 × (1−1.61%). The number of new IAC applications in year 0 is estimated at 197 by multiplying the estimated number of aggregate IACs in year 0 (3,648) by the average proportion of new IAC applications: 197 = 3,648 × 5.41%.
                    </P>
                </FTNT>
                <P>
                    The aggregate active population of IACs during a year is composed of IAC renewals and newly approved IAC applications. Since TSA calculates the number of newly approved IAC applications by assuming they are a constant proportion of the number of aggregate active IACs, then the number of renewals must be estimated applying the complementary proportion to the number of aggregate active IACs, as shown in column 
                    <E T="03">b</E>
                     of Table 3.
                    <SU>17</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         The number of IAC renewals is estimated applying the percentage complementary to the proportion of new IAC applications (1−5.41%) into the aggregate number of active IACs. For instance, the year 0 (2022) number of renewals is estimated multiplying the number of aggregate active IACs, or 3,648, by the complementary percentage of 94.59% to obtain 3,451 (3,648 × 94.59%). The number of IAC renewals can also be estimated subtracting the number of newly approved IAC applications from the number of aggregate active IACs.
                    </P>
                </FTNT>
                <P>
                    The exit rate of IAC in a given year is based on the subtraction of the given year's active IAC population from the preceding year's active IAC population, and the removal of the given year's newly approved IACs,
                    <SU>18</SU>
                    <FTREF/>
                     as displayed in column 
                    <E T="03">d</E>
                     of Table 2. Since the number of IAC exits is estimated based on the number of active IACs during the year and the number of newly approved IAC applications, an exit rate is derived from these two estimates for the purposes of compounding the number of exits over time. TSA calculates an IAC exit rate of 6.92 percent 
                    <SU>19</SU>
                    <FTREF/>
                     (
                    <E T="03">i.e.,</E>
                     do not resubmit or are not approved) from year to year. The exit rate in a specific year is the percentage of IACs that do not request their security program renewed 
                    <SU>20</SU>
                    <FTREF/>
                     out of the total number of IACs that had a security program in place before this year.
                </P>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         For example, calculations of Year 0, Year 1 and Year 2 IAC Exits are as follows:−257 (Year 0 Exits) = 3,648 (Year 0 Active IACs)−3,707 (Year−1 Active IACs)−197 (Year 0 Newly Approved IACs);−253 (Year 1 Exits) = 3,589 (Year 1 Active IACs)−3,648 (Year 0 Active IACs)−194 (Year 1 Newly Approved IACs); and−249 (Year 2 Exits) = 3,532 (Year 2 Active IACs)−3,395 (Year 1 Active IACs)−191 (Year 2 Newly Approved IACs).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         The exit rate is estimated by dividing the number of IAC exits by the aggregate number of active IACs in the previous year. For example, TSA estimates there would be 257 exits in year 0 (197 exits that were replaced by new entrants plus the 60 exits that decreased the aggregate population). TSA calculates a 6.92% exit rate in year 0 (257 exits ÷ 3,707 aggregate active IACs in year−1). This exit rate is the same throughout the 10-year period of analysis. The exit rate for future years can also be derived mathematically as follows: (Newly Approved IAC Proportion) × (1 + Active IAC Growth Rate)−(Active IAC Growth Rate), which numerically is equal to: 6.92% = 5.41% (1−1.61%)−(−1.61%).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         Firms do not get renewals either because a submission was not filed or was not approved.
                    </P>
                </FTNT>
                <P>
                    TSA estimates the total number of submissions in two blocks: the first block includes submissions associated with the current IAC population in each year, and the second block includes submissions from new applicants. This final rule is expected to be implemented in year 1 and the relevant prior year active IAC population will have, by then, a valid security plan; which will have to be renewed following the new 3-year cycle.
                    <SU>21</SU>
                    <FTREF/>
                     New applicants would also have to follow this 3-year renewal cycle. In both blocks, there is a share of IAC firms that will not renew their security plans during the next renewal event, and a share of IAC firms that will renew. The number of IACs resubmitting in a given year is estimated by multiplying the number of program submissions from 3 years prior by a factor that results from compounding the annual exit rate over 3 years; this retention factor, estimated to be 80.6 percent,
                    <SU>22</SU>
                    <FTREF/>
                     is multiplied by the number of program submissions from 3 years before estimate the number of renewals in the corresponding year.
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         It is assumed that the validity of security plans will be extended until year 1 once this action is executed. If an IAC firm in the year 0 population wants to remain active over the 10 years of analysis it will have to obtain four renewals during this period, in years 1, 4, 7, and 10.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         80.6% = (100%−6.92% exit rate)
                        <E T="51">(3-year cycle)</E>
                        .
                    </P>
                </FTNT>
                <P>
                    Table 3 staggers recertifications under the final rule's 3-year cycle 
                    <SU>23</SU>
                    <FTREF/>
                     in four separate columns for submissions one to four in the 10-year projection span. For example, TSA estimates that 2,738 of the 3,395 IAC recertifications in year 1 would resubmit their security programs in year 4,
                    <SU>24</SU>
                    <FTREF/>
                     and that 159 of the 197 new entrants in year 1 would resubmit for the first time in year 4 (see columns 
                    <E T="03">e</E>
                     and 
                    <E T="03">f</E>
                     regarding first and second submissions). In Table 3, TSA takes into account four recertification cycles 
                    <SU>25</SU>
                    <FTREF/>
                     within the 10-year framework (columns 
                    <E T="03">e</E>
                     through 
                    <E T="03">h</E>
                    ) and sums all the recertifications under the final rule in column 
                    <E T="03">i.</E>
                     Finally, TSA calculates the number of eliminated recertifications (column 
                    <E T="03">j</E>
                    ) by subtracting the final rule recertifications (column 
                    <E T="03">i</E>
                    ) from the baseline annual recertifications (column 
                    <E T="03">b</E>
                    ).
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         A cycle is the period in between renewals (or between the first renewal and the initial approval). The 3-year cycle means that submissions have to be renewed every 3 years. The current submission cycle is annual, one submission every year.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         Note IACs that were approved by TSA in year−1 (2 years before the start date of this rule) and partially in year 0 (1 year before the publication of this final rule) would need to resubmit 36 months from their last approval. IACs that were approved before the publication of the final rule (−1 &amp; 0) are included in year−1, for the purpose of this analysis. For example: (Year 4 Second Cycle Resubmissions) = (Year 1 Renewals) × 80.6%.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         The frequency in which an IAC must resubmit their security program for review.
                    </P>
                </FTNT>
                <PRTPAGE P="8554"/>
                <GPOTABLE COLS="11" OPTS="L2(,0,),p7,7/8,i1" CDEF="s25,10,10,10,15,10,10,10,10,10,10">
                    <TTITLE>Table 3—Number of Final Rule Eliminated Security Program Recertifications</TTITLE>
                    <BOXHD>
                        <CHED H="1">Year</CHED>
                        <CHED H="1">
                            Active IACs 
                            <SU>26</SU>
                        </CHED>
                        <CHED H="1">
                            Baseline recerts 
                            <SU>27</SU>
                        </CHED>
                        <CHED H="1">New IACs</CHED>
                        <CHED H="1">IAC exits</CHED>
                        <CHED H="1">
                            Recertification cycle 
                            <SU>28</SU>
                        </CHED>
                        <CHED H="2">1st</CHED>
                        <CHED H="2">2nd</CHED>
                        <CHED H="2">3rd</CHED>
                        <CHED H="2">4th</CHED>
                        <CHED H="1">Final rule recerts</CHED>
                        <CHED H="1">Eliminated recerts</CHED>
                    </BOXHD>
                    <ROW RUL="s">
                        <ENT I="25"> </ENT>
                        <ENT>
                            a(−1) =
                            <LI>initial pop a</LI>
                            <LI>= a(n−1) ×</LI>
                            <LI>(1−1.61%)</LI>
                        </ENT>
                        <ENT>
                            b1 = first
                            <LI>year</LI>
                            <LI>renewals</LI>
                            <LI>bn = an ×</LI>
                            <LI>(1−5.41%)</LI>
                        </ENT>
                        <ENT>
                            c = an ×
                            <LI>(5.41%)</LI>
                        </ENT>
                        <ENT>
                            dn =
                            <LI>(an−a(n−1))−cn</LI>
                        </ENT>
                        <ENT>
                            e1 = b1 en
                            <LI>= c(n−3)</LI>
                            <LI>× (0.806)</LI>
                        </ENT>
                        <ENT>
                            fn = e(n−3)
                            <LI>× (0.806)</LI>
                        </ENT>
                        <ENT>
                            gn = f(n−3)
                            <LI>× (0.806)</LI>
                        </ENT>
                        <ENT>
                            hn =
                            <LI>g(n−3)</LI>
                            <LI>× (0.806)</LI>
                        </ENT>
                        <ENT>
                            i = e + f +
                            <LI>g + h</LI>
                        </ENT>
                        <ENT>j = b−i</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>3,589</ENT>
                        <ENT>3,395</ENT>
                        <ENT>194</ENT>
                        <ENT>−253</ENT>
                        <ENT>3,395</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>3,395</ENT>
                        <ENT>0</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>3,532</ENT>
                        <ENT>3,341</ENT>
                        <ENT>191</ENT>
                        <ENT>−249</ENT>
                        <ENT>162</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>162</ENT>
                        <ENT>3,179</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>3,475</ENT>
                        <ENT>3,287</ENT>
                        <ENT>188</ENT>
                        <ENT>−245</ENT>
                        <ENT>159</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>159</ENT>
                        <ENT>3,128</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>3,419</ENT>
                        <ENT>3,234</ENT>
                        <ENT>185</ENT>
                        <ENT>−241</ENT>
                        <ENT>156</ENT>
                        <ENT>2,738</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>2,894</ENT>
                        <ENT>340</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>3,364</ENT>
                        <ENT>3,182</ENT>
                        <ENT>182</ENT>
                        <ENT>−237</ENT>
                        <ENT>154</ENT>
                        <ENT>130</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>284</ENT>
                        <ENT>2,898</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>3,310</ENT>
                        <ENT>3,131</ENT>
                        <ENT>179</ENT>
                        <ENT>−233</ENT>
                        <ENT>151</ENT>
                        <ENT>128</ENT>
                        <ENT>0</ENT>
                        <ENT>0</ENT>
                        <ENT>280</ENT>
                        <ENT>2,852</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>3,257</ENT>
                        <ENT>3,081</ENT>
                        <ENT>176</ENT>
                        <ENT>−229</ENT>
                        <ENT>149</ENT>
                        <ENT>126</ENT>
                        <ENT>2,207</ENT>
                        <ENT>0</ENT>
                        <ENT>2,483</ENT>
                        <ENT>598</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>3,205</ENT>
                        <ENT>3,032</ENT>
                        <ENT>173</ENT>
                        <ENT>−226</ENT>
                        <ENT>147</ENT>
                        <ENT>124</ENT>
                        <ENT>105</ENT>
                        <ENT>0</ENT>
                        <ENT>376</ENT>
                        <ENT>2,656</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>3,153</ENT>
                        <ENT>2,983</ENT>
                        <ENT>170</ENT>
                        <ENT>−222</ENT>
                        <ENT>144</ENT>
                        <ENT>122</ENT>
                        <ENT>103</ENT>
                        <ENT>0</ENT>
                        <ENT>370</ENT>
                        <ENT>2,613</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>3,103</ENT>
                        <ENT>2,935</ENT>
                        <ENT>168</ENT>
                        <ENT>−218</ENT>
                        <ENT>142</ENT>
                        <ENT>120</ENT>
                        <ENT>102</ENT>
                        <ENT>1,780</ENT>
                        <ENT>2,144</ENT>
                        <ENT>791</ENT>
                    </ROW>
                    <TNOTE>
                        <E T="02">Note:</E>
                         Calculations may not be exact due to rounding in the table.
                    </TNOTE>
                </GPOTABLE>
                <P>
                    TSA
                    <FTREF/>
                     estimates a time burden of 4 hours for an IAC manager to review and resubmit a security program. To calculate the hourly savings to industry, TSA multiplies the 4-hour burden by the fully loaded hourly wage rate for an IAC manager. TSA calculates the wage rate by estimating a weighted wage rate for two occupations across two industry subgroups.
                    <SU>29</SU>
                    <FTREF/>
                     To calculate the weighted wage rate, TSA multiplies each labor category wage rate by its respective number of employees, sums the product of these calculations, and then divides the result by the total number of employees across all four wage rates. Table 4 illustrates the weighted average wage calculation.
                </P>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         The active IAC population in subsequent years was estimated by applying the negative growth rate of 1.61% to the active IAC population. The negative growth rate represents the net change in the active IAC population accounting for IAC exits and entries. Year 1's value accounts for 3 years of negative growth derived from 3,768 IACs as of the end of fiscal year 2020 based on TSA records.
                    </P>
                    <P>
                        <SU>27</SU>
                         Baseline renewals represent Active IACs minus New IACs.
                    </P>
                    <P>
                        <SU>28</SU>
                         A retention factor of 0.806 is calculated as the exit rate of 6.92 percent compounded over 3 years to account for the number of IACs still operating who submitted a security program 3 years prior.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>29</SU>
                         Bureau of Labor Statistics (BLS), U.S. Department of Labor, May 2020 National Industry Specific Occupation Employment and Wage Estimates, First-Line Supervisors of Transportation and Material Moving Workers (SOC 53-1040) in Freight Transportation Arrangement (NAICS 488510) and Administrative Management and General Management Consulting Services (NAICS 541611), and to Transportation, Storage, and Distribution Managers (SOC 11-3071) in (NAICS 488510) and (NAICS 541611). (Accessed May 19, 2021 at 
                        <E T="03">https://www.bls.gov/oes/2020/may/naics4_541600.htm</E>
                         and 
                        <E T="03">https://www.bls.gov/oes/2020/may/naics4_488500.htm</E>
                        ).
                    </P>
                </FTNT>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r150,12,12">
                    <TTITLE>Table 4—Calculation of Weighted Average Industry Wage Rate</TTITLE>
                    <BOXHD>
                        <CHED H="1">Industry NAICS</CHED>
                        <CHED H="1">Occupations</CHED>
                        <CHED H="1">Wage rate</CHED>
                        <CHED H="2">a</CHED>
                        <CHED H="1">
                            Number of 
                            <LI>employees</LI>
                        </CHED>
                        <CHED H="2">b</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Freight Transportation Arrangement (488510)</ENT>
                        <ENT>First-Line Supervisors of Transportation and Material Moving Workers (53-1040)</ENT>
                        <ENT>$28.72</ENT>
                        <ENT>3,460</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Transportation, Storage, and Distribution Managers (11-3071)</ENT>
                        <ENT>46.41</ENT>
                        <ENT>4,920</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Management, Scientific, and Technical Consulting Services (541611)</ENT>
                        <ENT>First-Line Supervisors of Transportation and Material Moving Workers (53-1040)</ENT>
                        <ENT>27.52</ENT>
                        <ENT>3,190</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22"> </ENT>
                        <ENT>Transportation, Storage, and Distribution Managers (11-3071)</ENT>
                        <ENT>50.65</ENT>
                        <ENT>2,680</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="22">
                            Industry Weighted Average Wage Rate = ∑(a
                            <E T="52">i</E>
                             × b
                            <E T="52">i</E>
                            ) ÷ ∑b
                        </ENT>
                        <ENT A="01">$38.68</ENT>
                    </ROW>
                    <TNOTE>
                        <E T="02">Note:</E>
                         Calculations may not be exact due to rounding in the table.
                    </TNOTE>
                </GPOTABLE>
                <P>
                    Next, TSA adjusts this wage rate to account for employer benefits,
                    <SU>30</SU>
                    <FTREF/>
                     which results in an industry compensation rate of $57.90 per hour. Table 5 illustrates the calculation of the hourly industry compensation rate based on these adjustments.
                </P>
                <FTNT>
                    <P>
                        <SU>30</SU>
                         The average compensation factor is 1.4968. 1.4968 = (($31.76 + $30.89 + $30.99 + $30.40) ÷ 4) ÷ (($21.35 + $20.62 + $20.61 + $20.29) ÷ 4). The compensation factor is calculated based on the average of the quarterly total compensation divided by the average of the quarterly total wages. Source: BLS, News Releases, 
                        <E T="03">2020 Employer Costs for Employee Compensation,</E>
                         Table 4: Employer Costs for Employee Compensation for private industry workers by occupational and industry group (Transportation and Material Moving Occupational Group), as published in June 2020, September 2020, December 2020, and March 2021. (Accessed May 19, 2021 at 
                        <E T="03">https://www.bls.gov/bls/news-release/ecec.htm.</E>
                        )
                    </P>
                </FTNT>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="18C,18C,18C">
                    <TTITLE>Table 5—Calculation of Industry Compensation Rate</TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            Weighted wage rate 
                            <LI>(a)</LI>
                        </CHED>
                        <CHED H="1">
                            Benefits factor 
                            <LI>(b)</LI>
                        </CHED>
                        <CHED H="1">
                            Compensation rate 
                            <LI>(c = a × b)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">$38.68</ENT>
                        <ENT>1.4968</ENT>
                        <ENT>$57.90</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="8555"/>
                <P>
                    TSA multiplies 4 hours per resubmission by the $57.90 for an IAC manager to calculate a unit cost savings of $232 per recertification.
                    <SU>31</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>31</SU>
                         $231.61 Renewal Unit Cost to Industry = 4-Hour Renewal Time Burden × $57.90 Compensation Rate for IAC Managers.
                    </P>
                </FTNT>
                <P>
                    TSA estimates a duration of 2.25 hours for TSA staff to review a resubmission. The TSA review staff is composed of two “I” pay band members 
                    <SU>32</SU>
                    <FTREF/>
                     and four “J” pay band members. Each submission could be reviewed by any one of these staff members. TSA calculates a staff compensation rate based on the weighted average of two different TSA pay-bands that conduct reviews. To calculate the TSA weighted compensation rate, TSA multiplies the respective pay band compensation 
                    <SU>33</SU>
                    <FTREF/>
                     by the respective number of employees, sums the product of these calculations, and then divides by the total number of employees. Table 6 displays this weighted average calculation.
                </P>
                <FTNT>
                    <P>
                        <SU>32</SU>
                         TSA uses an SV pay grading system, which is a discrete salary system with pay ranges, incorporated into pay bands.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>33</SU>
                         TSA, DHS Modular Cost Standards, Washington DC Metropolitan Area Locality Pay, I-Band $70.62 = $147,382 annual compensation ÷ 2,087 hours and J-Band $83.17 = $173,585 annual compensation ÷ 2,087 hours (Office Personnel Management changed the 2,080 work hours for federal employees to 2,087 by amending 5 U.S.C. 5504(b). Source: Consolidated Omnibus Budget Reconciliation Act of 1985, Public Law 99-272 (100 Stat. 82; April 7, 1986).
                    </P>
                </FTNT>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s200,13,12">
                    <TTITLE>Table 6—Calculation of Weighted Average TSA Compensation Rate</TTITLE>
                    <BOXHD>
                        <CHED H="1">TSA pay band</CHED>
                        <CHED H="1">Compensation rate *</CHED>
                        <CHED H="2">a</CHED>
                        <CHED H="1">
                            Number of 
                            <LI>employees</LI>
                        </CHED>
                        <CHED H="2">b</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">TSA I Band</ENT>
                        <ENT>$70.62</ENT>
                        <ENT>2</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">TSA J Band</ENT>
                        <ENT>83.17</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Weighted Average TSA Compensation Rate = ∑(a
                            <E T="0732">i</E>
                             × b
                            <E T="0732">i</E>
                             ) ÷ ∑b
                        </ENT>
                        <ENT A="01">$78.99</ENT>
                    </ROW>
                    <TNOTE>* Compensation Rate includes employer benefits.</TNOTE>
                </GPOTABLE>
                <P>
                    TSA multiplies 2.25 hours by the TSA compensation rate of $78.99 per hour to obtain a unit cost savings per recertification of $178.
                    <SU>34</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>34</SU>
                         $177.73 Renewal Unit Cost to TSA = $78.99 I/J Band TSA Weighted Compensation Rate × 2.25 Hour Burden for Renewal Review.
                    </P>
                </FTNT>
                <P>
                    To calculate savings, TSA multiplies the number of eliminated resubmissions from column 
                    <E T="03">j</E>
                     of Table 3, by the respective unit cost savings for industry ($232) and TSA ($178). Table 7 displays the industry, TSA, and total savings from modifying the security program resubmission frequency from 1 to 3 years. TSA estimates that over 10 years cost savings aggregate to $7.8 million undiscounted, $6.6 million discounted at 3 percent, and $5.4 million discounted at 7 percent. The final rule would realize an annualized $0.8 million cost savings discounted at 7 percent over 10 years.
                </P>
                <GPOTABLE COLS="7" OPTS="L2,p7,7/8,i1" CDEF="s25,13,14,14,12,10,10">
                    <TTITLE>Table 7—Total Cost Savings From the Final Rule</TTITLE>
                    <TDESC>[$Thousands]</TDESC>
                    <BOXHD>
                        <CHED H="1">Year</CHED>
                        <CHED H="1">Eliminated resubmissions</CHED>
                        <CHED H="2">a</CHED>
                        <CHED H="1">Industry savings</CHED>
                        <CHED H="2">
                            b = a × $231.61 
                            <LI>÷ 1,000</LI>
                        </CHED>
                        <CHED H="1">TSA savings</CHED>
                        <CHED H="2">
                            c = a × $177.73 
                            <LI>÷ 1,000</LI>
                        </CHED>
                        <CHED H="1">
                            (Cost savings)
                            <LI>d = ∑b,c</LI>
                        </CHED>
                        <CHED H="2">Undiscounted</CHED>
                        <CHED H="2">Discounted at 3%</CHED>
                        <CHED H="2">Discounted at 7%</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT/>
                        <ENT>$0</ENT>
                        <ENT>$0</ENT>
                        <ENT>$0</ENT>
                        <ENT>$0</ENT>
                        <ENT>$0</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>3,179</ENT>
                        <ENT>736</ENT>
                        <ENT>565</ENT>
                        <ENT>1,301</ENT>
                        <ENT>1,227</ENT>
                        <ENT>1,137</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>3,128</ENT>
                        <ENT>725</ENT>
                        <ENT>556</ENT>
                        <ENT>1,280</ENT>
                        <ENT>1,172</ENT>
                        <ENT>1,045</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>340</ENT>
                        <ENT>79</ENT>
                        <ENT>60</ENT>
                        <ENT>139</ENT>
                        <ENT>124</ENT>
                        <ENT>106</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>2,898</ENT>
                        <ENT>671</ENT>
                        <ENT>515</ENT>
                        <ENT>1,186</ENT>
                        <ENT>1,023</ENT>
                        <ENT>846</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>2,852</ENT>
                        <ENT>660</ENT>
                        <ENT>507</ENT>
                        <ENT>1,167</ENT>
                        <ENT>978</ENT>
                        <ENT>778</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>598</ENT>
                        <ENT>139</ENT>
                        <ENT>106</ENT>
                        <ENT>245</ENT>
                        <ENT>199</ENT>
                        <ENT>153</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>2,656</ENT>
                        <ENT>615</ENT>
                        <ENT>472</ENT>
                        <ENT>1,087</ENT>
                        <ENT>858</ENT>
                        <ENT>633</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>2,613</ENT>
                        <ENT>605</ENT>
                        <ENT>464</ENT>
                        <ENT>1,070</ENT>
                        <ENT>820</ENT>
                        <ENT>582</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">10</ENT>
                        <ENT>791</ENT>
                        <ENT>183</ENT>
                        <ENT>141</ENT>
                        <ENT>324</ENT>
                        <ENT>241</ENT>
                        <ENT>165</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="03">Total</ENT>
                        <ENT>19,056</ENT>
                        <ENT>4,413</ENT>
                        <ENT>3,387</ENT>
                        <ENT>7,800</ENT>
                        <ENT>6,641</ENT>
                        <ENT>5,443</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">Annualized</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>$775</ENT>
                        <ENT>$779</ENT>
                    </ROW>
                    <TNOTE>
                        <E T="02">Note:</E>
                         Calculation may not be exact in table due to rounding.
                    </TNOTE>
                </GPOTABLE>
                <HD SOURCE="HD2">B. Small Entities</HD>
                <P>
                    As required by the Regulatory Flexibility Act,
                    <SU>35</SU>
                    <FTREF/>
                     TSA considered whether this final rule would have a significant economic impact on a substantial number of small entities, including small businesses and not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. This rule does not place any new requirements on the regulated industry or small businesses. In addition, TSA received no comments related to the regulatory impact analysis in the NPRM, therefore has made no changes to this analysis in the final rule. TSA has certified that this rule does not have a significant economic impact on a substantial number of small entities.
                </P>
                <FTNT>
                    <P>
                        <SU>35</SU>
                         
                        <E T="03">See</E>
                         Public Law 96-354 (94 Stat. 1164; Sept. 19, 1980) as codified at 5 U.S.C. 601 
                        <E T="03">et seq.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Collection of Information</HD>
                <P>
                    The Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3501. 
                    <E T="03">et seq.</E>
                    ) requires that TSA consider the impact of paperwork and other information collection burdens imposed on the 
                    <PRTPAGE P="8556"/>
                    public and, under the provisions of 44 U.S.C. 3507(d), obtain approval from the OMB for each collection of information it conducts, sponsors, or requires through regulations. As provided by the PRA, as amended, an agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number. The collection of information covered by this final rule is covered by OMB control number 1652-0040.
                </P>
                <P>This final rule impacts the collection of information by reducing the frequency that information must be submitted. This reduction would decrease the current number of security program recertifications submitted from an estimated annual average of 3,700 to 1,239 responses (a reduction of 2,461). The corresponding burden is also reduced from an annual average of 14,800 hours to 4,956 hours (a reduction of 9,844 hours). Table 8 displays the annual number of responses and burden hour estimates associated with the final rule.</P>
                <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s25,7C,7C,7C,10C,10C,10C,11C,11C">
                    <TTITLE>Table 8—PRA Information Collection Responses and Burden Hours</TTITLE>
                    <BOXHD>
                        <CHED H="1">Collection activity</CHED>
                        <CHED H="1">Responses</CHED>
                        <CHED H="2">Year 1</CHED>
                        <CHED H="2">Year 2</CHED>
                        <CHED H="2">Year 3</CHED>
                        <CHED H="2">
                            Total 
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="2">
                            Average 
                            <LI>annual </LI>
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="2">
                            Time 
                            <LI>burden per </LI>
                            <LI>response </LI>
                            <LI>(hours)</LI>
                        </CHED>
                        <CHED H="1">Total hours</CHED>
                        <CHED H="1">
                            Average
                            <LI>annual</LI>
                            <LI>hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Final Rule Recerts</ENT>
                        <ENT>3,395</ENT>
                        <ENT>162</ENT>
                        <ENT>159</ENT>
                        <ENT>3,716</ENT>
                        <ENT>1,239</ENT>
                        <ENT/>
                        <ENT>4,956</ENT>
                        <ENT>1,652</ENT>
                    </ROW>
                </GPOTABLE>
                <P>As required by the PRA (44 U.S.C. 3507(d)), TSA has submitted a copy of the final rule to the OMB for its review of the collection of information.</P>
                <HD SOURCE="HD2">D. International Trade Impact Assessment</HD>
                <P>
                    The Trade Agreements Act of 1979 
                    <SU>36</SU>
                    <FTREF/>
                     prohibits Federal agencies from establishing any standards or engaging in related activities that create unnecessary obstacles to the foreign commerce of the United States. Pursuant to these requirements, the establishment of standards is not considered an unnecessary obstacle to the foreign commerce of the United States, so long as the standard has a legitimate domestic objective, such as the protection of safety, and does not operate in a manner that excludes imports that meet this objective. The statute also requires consideration of international standards and, where appropriate, that they be the basis for U.S. standards. TSA has assessed the potential effect of the final rule and has determined that it does not impose any new requirements. Therefore, the rule would not have an adverse impact on international trade.
                </P>
                <FTNT>
                    <P>
                        <SU>36</SU>
                         
                        <E T="03">See</E>
                         Public Law 96-39 (93 Stat. 144; July 26, 1979) as amended by the Uruguay Round Agreements Act, Public Law 103-465 (108 Stat 4809; Dec. 8, 1994), codified at 19 U.S.C. 2531-2533.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">E. Unfunded Mandates Assessment</HD>
                <P>
                    Title II of the Unfunded Mandates Reform Act of 1995 
                    <SU>37</SU>
                    <FTREF/>
                     establishes requirements for Federal agencies to assess the effects of their regulatory actions on State, local, and tribal governments and the private sector. Under sec. 202 of the Unfunded Mandates Reform Act, TSA generally must prepare a written statement, including a cost-benefit analysis, for proposed and final rules with “Federal mandates” that may result in expenditures by State, local, and tribal governments in the aggregate or by the private sector of $100 million (adjusted for inflation) or more in any one year. The final rule does not contain such a mandate. Therefore, the written statement requirements of the Act do not apply.
                </P>
                <FTNT>
                    <P>
                        <SU>37</SU>
                         
                        <E T="03">See</E>
                         Public Law 104-4 (109 Stat. 48; Mar. 22, 1995), codified at 2 U.S.C. 1501-1538.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">F. Environment</HD>
                <P>TSA has reviewed this rulemaking for purposes of the National Environmental Policy Act of 1969 (NEPA) (42 U.S.C. 4321-4347) and has determined that this action will not have a significant effect on the human environment. This action is covered by categorical exclusion number A3(b) in DHS Management Directive 023-01 (formerly Management Directive 5100.1), Environmental Planning Program, which guides TSA compliance with NEPA.G. International Compatibility and Cooperation.</P>
                <P>
                    E.O. 13609 of May 1, 2012 (Promoting International Regulatory Cooperation),
                    <SU>38</SU>
                    <FTREF/>
                     promotes international regulatory cooperation to meet shared challenges involving health, safety, labor, security, environmental, and other issues and to reduce, eliminate, or prevent unnecessary differences in regulatory requirements. TSA analyzed this action under the policies and agency responsibilities of E.O. 13609, and has determined that this action would have no effect on international regulatory cooperation. In keeping with U.S. obligations under the Convention on International Civil Aviation (also known as the “Chicago Convention”), it is TSA policy to comply with International Civil Aviation Organization Standards and Recommended Practices to the maximum extent practicable. TSA has determined that this regulation has no direct relationship to the Chicago Convention.
                </P>
                <FTNT>
                    <P>
                        <SU>38</SU>
                         Published at 77 FR 26413 (May 4, 2012).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">H. Executive Order 13132, Federalism</HD>
                <P>
                    TSA has analyzed this rule under the principles and criteria of E.O. 13132 of August 4, 1999 (Federalism).
                    <SU>39</SU>
                    <FTREF/>
                     TSA has determined that this action will not have a substantial direct effect on the States, or the relationship between the Federal Government and the States, or on the distribution of power and responsibilities among the various levels of government, and, therefore, does not have federalism implications.
                </P>
                <FTNT>
                    <P>
                        <SU>39</SU>
                         Published at 64 FR 43255 (Aug. 10, 1999).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">I. Energy Impact Analysis</HD>
                <P>The energy impact of this rulemaking has been assessed in accordance with the Energy Policy and Conservation Act (EPCA), Public Law 94-163, as amended (42 U.S.C. 6362). TSA has determined that this rulemaking would not be a major regulatory action under the provisions of the EPCA.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 49 CFR Part 1548</HD>
                    <P>Air transportation, Reporting and recordkeeping requirements, Security measures.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Amendment</HD>
                <P>For the reasons set forth in the preamble, the Transportation Security Administration amends chapter XII of title 49, Code of Federal Regulations, as follows:</P>
                <SUBCHAP>
                    <PRTPAGE P="8557"/>
                    <HD SOURCE="HED">Subchapter C—Civil Aviation Security</HD>
                    <PART>
                        <HD SOURCE="HED">PART 1548—INDIRECT AIR CARRIER SECURITY</HD>
                    </PART>
                </SUBCHAP>
                <REGTEXT TITLE="49" PART="1548">
                    <AMDPAR>1. The authority citation for part 1548 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 49 U.S.C. 114, 5103, 40113, 44901-44905, 44913-44914, 44916-44917, 44932, 44935-44936, 46105.</P>
                    </AUTH>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 1548.7 </SECTNO>
                    <SUBJECT>[Amended] </SUBJECT>
                </SECTION>
                <REGTEXT TITLE="49" PART="1548">
                    <AMDPAR>2. Amend § 1548.7 by:</AMDPAR>
                    <AMDPAR>a. In paragraph (a)(4), removing the words “one year after the month it was approved” and adding in their place “3 years after the month it was approved, or until the program has been surrendered or withdrawn, whichever is earlier”.</AMDPAR>
                    <AMDPAR>b. In paragraph (a)(5) introductory text, adding the words “or renewal” after the words “submitted during its initial”.</AMDPAR>
                    <AMDPAR>c. In paragraph (b)(1), removing the words “at least 30 calendar days prior to the first day of the anniversary month of initial approval” and adding in their place “at least 30 calendar days before the 36th month after the initial approval”.</AMDPAR>
                    <AMDPAR>d. In paragraph (b)(4), removing the words “one year after the month it was renewed” and adding in their place “3 years after the month it was renewed, or until the program has been surrendered or withdrawn, whichever is earlier”.</AMDPAR>
                </REGTEXT>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>David P. Pekoske,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02495 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-05-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 217</CFR>
                <SUBJECT>Regulations Governing the Take of Marine Mammals Incidental to Specified Activities</SUBJECT>
                <HD SOURCE="HD2">CFR Correction</HD>
                <P>This rule is being published by the Office of the Federal Register to correct an editorial or technical error that appeared in the most recent annual revision of the Code of Federal Regulations.</P>
                <REGTEXT TITLE="50" PART="217">
                    <AMDPAR>In Title 50 of the Code of Federal Regulations, Parts 200 to 227, revised as of October 1, 2023, remove Subpart I to Part 217.</AMDPAR>
                </REGTEXT>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02695 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 0099-10-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 648</CFR>
                <DEPDOC>[240202-0033]</DEPDOC>
                <RIN>RIN 0648-XD495</RIN>
                <SUBJECT>Fisheries of the Northeastern United States; Atlantic Deep-Sea Red Crab Fishery; 2024 Atlantic Deep-Sea Red Crab Specifications</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>NMFS is approving specifications for the 2024-2027 Atlantic deep-sea red crab fishery, including the annual catch limits and total allowable landings limits. This action implements the allowable 2024 harvest levels, consistent with the Atlantic Deep-Sea Red Crab Fishery Management Plan. This action is necessary to establish allowable red crab harvest levels that will prevent overfishing.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The final specifications for the 2024 Atlantic deep-sea red crab fishery are effective March 11, 2024, through February 28, 2025.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Copies of the supplemental information report, including the Regulatory Flexibility Act Analysis and other supporting documents for the specifications, are available from Dr. Cate O'Keefe, Executive Director, New England Fishery Management Council, 50 Water Street, Mill 2, Newburyport, MA 01950 or at 
                        <E T="03">https://www.nefmc.org/library/2024-2027-red-crab-specifications.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Allison Murphy, Fishery Policy Analyst, (978) 281-9122.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>The Atlantic deep-sea red crab fishery is managed by the New England Fishery Management Council (Council). The Atlantic Deep-Sea Red Crab Fishery Management Plan (FMP) includes a specification process that requires the Council to recommend, on a triennial basis, an acceptable biological catch (ABC), an annual catch limit (ACL), and total allowable landings (TAL) every 4 years. The Council's Scientific and Statistical Committee (SSC) provides a recommendation to the Council for the ABC. The Council makes a recommendation to NMFS on the ABC, which cannot exceed the ABC recommendation made by the SSC.</P>
                <HD SOURCE="HD1">Final Specifications</HD>
                <P>The biological and management reference points currently in the FMP are used to determine whether overfishing is occurring or if the stock is overfished. There is insufficient information on the species to establish the maximum sustainable yield, optimum yield, or overfishing limit. The ABC is defined in terms of landings instead of total catch because there is insufficient information to estimate dead discards of red crab. We are approving the Council-recommended specifications for the 2024-2027 fishing years that establish a 2,000-metric ton ABC, ACL, and TAL. This action implements these specifications for the 2024 fishing year.</P>
                <P>
                    At the end of each fishing year, we evaluate catch information and determine if the quota has been exceeded. If a quota is exceeded, the regulations at 50 CFR 648.262(b) require a pound-for-pound reduction of the quota in a subsequent fishing year. NMFS will publish a notice in the 
                    <E T="04">Federal Register</E>
                     of any revisions to the projected specifications if an overage occurs. Based on the performance of the 2023 red crab fishery, no adjustment is necessary for fishing year 2024. NMFS will provide notice of the final 2025-2027 quotas, and any necessary reductions, prior to the start of each respective fishing year.
                </P>
                <HD SOURCE="HD1">Comments and Responses</HD>
                <P>The public comment period for the proposed rule (88 FR 83893, December 1, 2023) ended on January 2, 2024. No comments were received on the proposed rule.</P>
                <HD SOURCE="HD1">Changes From the Proposed Rule</HD>
                <P>There are no changes from the proposed rule.</P>
                <HD SOURCE="HD1">Classification</HD>
                <P>Pursuant to section 304(b)(1)(A) of the Magnuson-Stevens Act, the NMFS Assistant Administrator has determined that this final rule is consistent with the Atlantic Deep-Sea Red Crab FMP, other provisions of the Magnuson-Stevens Act, and other applicable law.</P>
                <P>This final rule is exempt from review under Executive Order 12866.</P>
                <P>
                    The Chief Counsel for Regulation, Department of Commerce, certified to the Chief Counsel for Advocacy of the Small Business Administration (SBA) during the proposed rule stage that this action would not have a significant economic impact on a substantial 
                    <PRTPAGE P="8558"/>
                    number of small entities. The factual basis for the certification was published in the proposed rule and is not repeated here. No comments were received regarding this certification. As a result, a regulatory flexibility analysis was not required and none was prepared.
                </P>
                <P>This action does not contain a collection of information requirement for purposes of the Paperwork Reduction Act.</P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Samuel D. Rauch, III,</NAME>
                    <TITLE>Deputy Assistant Administrator for Regulatory Programs, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02516 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </RULE>
    </RULES>
    <VOL>89</VOL>
    <NO>27</NO>
    <DATE>Thursday, February 8, 2024</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <PRORULES>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="8559"/>
                <AGENCY TYPE="F">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Parts 1, 21, 22, 36, 43, 45, 61, 65, 91, and 119</CFR>
                <DEPDOC>[Docket No.: FAA-2023-1377; Notice No. 23-10]</DEPDOC>
                <RIN>RIN 2120-AL50</RIN>
                <SUBJECT>Modernization of Special Airworthiness Certification</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking (NPRM); reopening of comment period.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This action extends the comment period for the NPRM published on July 24, 2024, titled “Modernization of Special Airworthiness Certification.” The FAA is extending the comment period to allow commenters to review and comment on a Memorandum to the Docket that the FAA posted to the docket (FAA-2023-1377-1343) on February 1, 2024, regarding an ex parte communication between the FAA and representatives of ASTM International regarding the NPRM.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The comment period for the NPRM published on July 24, 2023, at 88 FR 47650 and extended on October 4, 2023, at 88 FR 68507, and closed on January 22, 2024, is reopened until March 11, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Send comments identified by docket number FAA-2023-1377 using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">www.regulations.gov</E>
                         and follow the online instructions for sending your comments electronically.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Send comments to Docket Operations, M-30; U.S. Department of Transportation (DOT), 1200 New Jersey Avenue SE, Room W12-140, West Building Ground Floor, Washington, DC 20590-0001.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         Take comments to Docket Operations in Room W12-140 of the West Building Ground Floor at 1200 New Jersey Avenue SE, Washington, DC, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         Fax comments to Docket Operations at (202) 493-2251.
                    </P>
                    <P>
                        <E T="03">Privacy:</E>
                         In accordance with 5 U.S.C. 553(c), DOT solicits comments from the public to better inform its rulemaking process. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                        <E T="03">www.regulations.gov,</E>
                         as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                        <E T="03">www.dot.gov/privacy.</E>
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         Background documents or comments received may be read at 
                        <E T="03">www.regulations.gov</E>
                         at any time. Follow the online instructions for accessing the docket or go to the Docket Operations in Room W12-140 of the West Building Ground Floor at 1200 New Jersey Avenue SE, Washington, DC, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For technical questions concerning this action, contact James Newberger, Aircraft Certification Service (AIR-632), Federal Aviation Administration, 800 Independence Ave. SW, Washington, DC 20591, telephone (202) 267-1636; email 
                        <E T="03">james.e.newberger@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD2">A. Comments Invited</HD>
                <P>The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. 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.</P>
                <P>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.</P>
                <HD SOURCE="HD2">B. Confidential Business Information</HD>
                <P>
                    Confidential Business Information (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 the person listed under the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     heading at the beginning of the preamble. Any commentary that the FAA receives which is not specifically designated as CBI will be placed in the public docket for this rulemaking.
                </P>
                <HD SOURCE="HD2">C. Availability of Rulemaking Documents</HD>
                <P>An electronic copy of rulemaking documents may be obtained from the internet by—</P>
                <P>
                    1. Searching the Federal eRulemaking Portal at 
                    <E T="03">www.regulations.gov;</E>
                </P>
                <P>
                    2. Visiting the FAA's Regulations and Policies web page at 
                    <E T="03">www.faa.gov/regulations_policies/;</E>
                     or
                </P>
                <P>
                    3. Accessing the Government Printing Office's web page at 
                    <E T="03">www.GovInfo.com.</E>
                </P>
                <P>Copies may also be obtained by sending a request to the Federal Aviation Administration, Office of Rulemaking, ARM-1, 800 Independence Avenue SW, Washington, DC 20591, or by calling (202) 267-9680. Commenters must identify the docket or notice number of this rulemaking.</P>
                <P>All documents the FAA considered in developing this proposed rule, including economic analyses and technical reports, may be accessed from the internet through the Federal eRulemaking Portal referenced in item (1) above.</P>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On July 24, 2023, the FAA published an NPRM titled “Modernization of Special Airworthiness Certification” in 
                    <PRTPAGE P="8560"/>
                    the 
                    <E T="04">Federal Register</E>
                     (88 FR 47650; Notice No. 23-10). Commenters were instructed to provide comments on or before October 23, 2023 (
                    <E T="03">i.e.,</E>
                     90 days from the date of publication of the NPRM). However, based on numerous requests to extend the comment period, the FAA extended the comment period on October 4, 2023 (88 FR 68507) to January 22, 2024 (
                    <E T="03">i.e.,</E>
                     an additional 90 days for a total of 180 days from the date of publication of the NPRM).
                </P>
                <P>Throughout the comment period, the rulemaking team assigned to this rulemaking project met to discuss the comments received. At a recent meeting of the rulemaking team, the FAA became aware of a conversation that was held between one of the members of the team and members of ASTM International (“ASTM”) regarding the contents of the NPRM during the ASTM International Fall Committee Week at a meeting of the ASTM International, Committee F37 on Light-Sport Aircraft. At the time, that team member recommended that the members of ASTM Committee F37 submit their comments to the docket. In the interest of transparency, the FAA is taking two steps. First, a Memorandum to the Docket (the “Memorandum”) summarizing the conversation between ASTM Committee F37 and the FAA has been placed on the docket as of February 1, 2024. Second, the FAA is reopening the comment period for thirty (30) days to allow the public an opportunity to review the contents of the Memorandum and an opportunity to respond if desired. Commenters should limit comments during this extension to the contents of the Memorandum.</P>
                <HD SOURCE="HD1">Reopening of Comment Period</HD>
                <P>Under the above circumstances, the FAA finds that an additional thirty (30) days will provide sufficient opportunity for the public to comment on the Memorandum. Therefore, the comment period for Notice No. 23-10 is reopened until March 11, 2024.</P>
                <P>The FAA will not extend the comment period for this rulemaking further.</P>
                <P>Issued under authority provided by 49 U.S.C. 106(f), 44701(a), and 44703 in Washington, DC.</P>
                <SIG>
                    <NAME>Brandon Roberts,</NAME>
                    <TITLE>Executive Director, Office of Rulemaking, Federal Aviation Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02545 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Parts 3, 21, 43, 60, 61, 63, 65, 67, 89, 107, 111, 120, 121, 139, 142, 145, 413</CFR>
                <DEPDOC>[Docket No.: FAA-2024-0021; Notice No. 24-07]</DEPDOC>
                <RIN>RIN 2120-AL84</RIN>
                <SUBJECT>Falsification, Reproduction, Alteration, Omission, or Incorrect Statements</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking (NPRM).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA proposes to amend, restructure, and consolidate the falsification regulations presently located throughout title 14 of the Code of Federal Regulations. This proposal would (1) harmonize inconsistencies among the various falsification regulations and associated sanctions; (2) consolidate all existing falsification regulations into a general rule that standardizes the existing falsification regulations; and (3) ensure that falsification-related conduct not addressed by pertinent current regulations would be covered under the general rule. In addition, this proposal would create a falsification prohibition applicable to the regulations governing Commercial Space Transportation.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Send comments on or before April 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Send comments identified by docket number FAA-2024-0021 using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">www.regulations.gov/</E>
                         and follow the online instructions for sending your comments electronically.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Send comments to Docket Operations, M-30; U.S. Department of Transportation (DOT), 1200 New Jersey Avenue, SE, Room W12-140, West Building Ground Floor, Washington, DC 20590-0001.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         Take comments to Docket Operations in Room W12-140 of the West Building Ground Floor at 1200 New Jersey Avenue, SE, Washington, DC, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         Fax comments to Docket Operations at (202) 493-2251.
                    </P>
                    <P>
                        <E T="03">Privacy:</E>
                         In accordance with 5 U.S.C. 553(c), DOT solicits comments from the public to better inform its rulemaking process. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                        <E T="03">www.regulations.gov</E>
                        , as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                        <E T="03">www.dot.gov/privacy.</E>
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         Background documents or comments received may be read at 
                        <E T="03">www.regulations.gov</E>
                         at any time. Follow the online instructions for accessing the docket or go to the Docket Operations in Room W12-140 of the West Building Ground Floor at 1200 New Jersey Avenue, SE, Washington, DC, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        John C. Stuart, Jr., Senior Attorney, Aviation Litigation Division, AGC-300, Federal Aviation Administration, Office of the Chief Counsel, 800 Independence Avenue SW, Washington, DC 20591; telephone (202) 267-9958; email 
                        <E T="03">mike.stuart@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Executive Summary</FP>
                    <FP SOURCE="FP1-2">A. Overview of Proposed Rule</FP>
                    <FP SOURCE="FP1-2">B. Background</FP>
                    <FP SOURCE="FP1-2">C. Statement of the Problem</FP>
                    <FP SOURCE="FP1-2">D. Summary of the Costs and Benefits</FP>
                    <FP SOURCE="FP-2">II. Authority for This Rulemaking</FP>
                    <FP SOURCE="FP-2">III. Discussion of the Proposal</FP>
                    <FP SOURCE="FP1-2">A. Applicability of the Proposed Rulemaking to 14 CFR Chapter I</FP>
                    <FP SOURCE="FP1-2">B. Applicability of the Proposed Rulemaking to 14 CFR Chapter III</FP>
                    <FP SOURCE="FP1-2">C. “Statements” in Proposed Sections 3.403(a), 3.405(a), 402.3(a), and 402.5(a)</FP>
                    <FP SOURCE="FP1-2">D. Categories of “Any Document In Any Format” in Proposed Sections 3.403 and 3.405—14 CFR Chapter I</FP>
                    <FP SOURCE="FP1-2">E. Categories of “Any Document In Any Format” in Proposed Sections 402.3 and 402.5—14 CFR Chapter III</FP>
                    <FP SOURCE="FP1-2">F. Fraudulent or Intentionally False Statements in Proposed Sections 3.403(a) and 402.3(a)</FP>
                    <FP SOURCE="FP1-2">G. Production, Reproduction, Alteration, for Fraudulent Purpose in Proposed Sections 3.403(b) and 402.3(b)</FP>
                    <FP SOURCE="FP1-2">H. Knowingly Omitting or Causing To Be Omitted a Material Fact Under Proposed Sections 3.403(c) and 402.3(c)</FP>
                    <FP SOURCE="FP1-2">I. Sanction Under Proposed Sections 3.403(d) and 402.3(d) for Conduct Described in Sections F, G, and H of this NPRM</FP>
                    <FP SOURCE="FP1-2">J. Incorrect Statements, or Omissions under Proposed Sections 3.405 and 402.5.</FP>
                    <FP SOURCE="FP1-2">K. Sanction Under Sections 3.405(b) and 402.5(b) for Incorrect Statements, or Omissions</FP>
                    <FP SOURCE="FP-2">IV. Regulatory Notices and Analyses</FP>
                    <FP SOURCE="FP1-2">A. Regulatory Evaluation</FP>
                    <FP SOURCE="FP1-2">B. Regulatory Flexibility Act</FP>
                    <FP SOURCE="FP1-2">C. International Trade Impact Assessment</FP>
                    <FP SOURCE="FP1-2">D. Unfunded Mandates Assessment</FP>
                    <FP SOURCE="FP1-2">E. Paperwork Reduction Act</FP>
                    <FP SOURCE="FP1-2">F. International Compatibility</FP>
                    <FP SOURCE="FP1-2">G. Environmental Analysis</FP>
                    <FP SOURCE="FP-2">V. Executive Order Determinations</FP>
                    <FP SOURCE="FP1-2">
                        A. Executive Order 13132, Federalism
                        <PRTPAGE P="8561"/>
                    </FP>
                    <FP SOURCE="FP1-2">B. Executive Order 13175, Consultation and Coordination With Indian Tribal Governments</FP>
                    <FP SOURCE="FP1-2">C. Executive Order 13211, Regulations That Significantly Affect Energy Supply, Distribution, or Use</FP>
                    <FP SOURCE="FP1-2">D. Executive Order 13609, Promoting International Regulatory Cooperation</FP>
                    <FP SOURCE="FP-2">VI. Additional Information</FP>
                    <FP SOURCE="FP1-2">A. Comments Invited</FP>
                    <FP SOURCE="FP1-2">B. Availability of Rulemaking Documents</FP>
                    <FP SOURCE="FP1-2">C. Small Business Regulatory Enforcement Fairness Act</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Executive Summary</HD>
                <HD SOURCE="HD2">A. Overview of Proposed Rule</HD>
                <P>The FAA and other relevant stakeholders rely on complete and accurate information in safety-related records. Indeed, the FAA and regulated persons make critical safety-related decisions based on the information, such as in FAA-required records, and necessarily rely on the veracity of that information. When a person provides falsified information or omits material information from records, that person creates a threat to aviation safety by inhibiting the ability of the FAA and other stakeholders to make critical safety-related decisions. Falsification regulations promote the integrity of information necessary to ensure aviation safety. They also serve as a basis for appropriate action when a person engages in falsification-related conduct.</P>
                <P>The proposed rule would affect applicable parts in 14 CFR chapters I and III. Falsification prohibitions are currently found in 14 CFR chapter I, parts 3, 21, 43, 60, 61, 63, 65, 67, 89, 107, 111, 120, 121, 139, 142, and 145. The FAA proposes to remove the existing falsification regulations from parts 21, 43, 60, 61, 63, 65, 67, 89, 107, 111, 120, 121, 139, 142, and 145, and consolidate them in a new subpart in part 3. The proposed rule in part 3 would also apply to those parts of 14 CFR chapter I that do not currently have falsification regulations but for which such regulations are clearly warranted, as explained in the “Discussion of the Proposal Section” in this NPRM. Those parts are 5, 23, 25, 26, 27, 29, 31, 33, 34, 35, 36, 45, 47, 48, 49, 68, 77, 91, 93, 99, 101, 103, 105, 117, 119, 125, 129, 133, 135, 136, 137, 141, 147, and 183. As a result, the proposed rule in part 3 would create standardized falsification proscriptions and apply them to 14 CFR parts 5, 21, 23, 25, 26, 27, 29, 31, 33, 34, 35, 36, 43, 45, 47, 48, 49, 60, 61, 63, 65, 67, 68, 77, 89, 91, 93, 99, 101, 103, 105, 107, 111, 117, 119, 120, 121, 125, 129, 133, 135, 136, 137, 139, 141, 142, 145, 147, and 183.</P>
                <P>The proposed rule would also remove the existing falsification regulations located in 14 CFR 413.17(c) and create a new part—part 402—containing a falsification prohibition applicable to 14 CFR chapter III, subchapter C. Subchapter C consists of 14 CFR parts 413, 414, 415, 417, 420, 431, 433, 435, 437, 440, 450, and 460.</P>
                <P>The proposed rules in part 3 and part 402 would proscribe: (1) intentionally false or fraudulent statements; (2) productions, reproductions, or alterations for fraudulent purpose; (3) knowingly omitting or causing to be omitted a material fact; and (4) incorrect statements. Each prohibition is described in the “Discussion of the Proposal” section of this NPRM. Also, the proposed rule would standardize sanctions for violations of the falsification regulations under 14 CFR, chapters I and III, cited in this NPRM.</P>
                <HD SOURCE="HD2">B. Background</HD>
                <HD SOURCE="HD3">1. Definition of “falsification regulations” and Current Locations in 14 CFR</HD>
                <P>The term “falsification regulations” as used in this NPRM generically refers to a variety of provisions in 14 CFR parts 1-199 implemented over decades that variously prohibit the following: (1) fraudulent or intentionally false statements or entries; (2) any reproduction for fraudulent purpose; (3) any alteration, including alterations for fraudulent purpose; (4) knowingly concealing or causing to be concealed a material fact by omission; (5) concealing or causing to be concealed a material fact; (6) known omissions; (7) misleading statements; and (8) incorrect statements or entries upon which the FAA relied or could have relied. The term also refers to willful false statements prohibited in 14 CFR 413.17(c). A violation of these standards is referenced in this NPRM as “falsification-related” conduct. The proposed rulemaking would consolidate these nine categories of proscribed conduct into the four categories identified above.</P>
                <P>
                    A false statement is distinct from an intentionally false or fraudulent one. A false statement or entry 
                    <SU>1</SU>
                    <FTREF/>
                     is one that is incorrect. An incorrect statement or entry is made when a person unknowingly provides false (
                    <E T="03">i.e.,</E>
                     incorrect) information upon which the agency relies. Incorrect statements or entries are prohibited by 14 CFR 60.33(c)(1)-(2) and 67.403. In contrast, an intentional false statement is comprised of three elements: a (1) false statement, (2) in reference to a material fact,
                    <SU>2</SU>
                    <FTREF/>
                     (3) that is made with knowledge of its falsity.
                    <SU>3</SU>
                    <FTREF/>
                     A fraudulent statement or entry consists of the preceding three elements plus two additional elements: (1) an intent to deceive and (2) with action taken in reliance upon the representation.
                    <SU>4</SU>
                    <FTREF/>
                     Intentionally false or fraudulent statements or entries are currently proscribed by 14 CFR 21.2(a)(1)-(2), 43.12(a)(1), 60.33(a)(1)-(2), 61.59(a)(1)-(2), 63.20(a)(1)-(2), 65.20(a)(1)-(2), 67.403(a)(1)-(2), 89.5(a)(1)-(2), 107.5(a)(1), 111.35(a)-(c), 120.103(e)(1)-(2), 121.9(a)(1)-(2), 139.115(a)(1)-(2), and 145.12(a)(1).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Over the years, the agency's use of the terms “statement” and “entry” has varied. In the earliest falsification regulations (
                        <E T="03">i.e.,</E>
                         in 1965), a clear dichotomy existed between statements and entries: a statement applied to an application while an entry applied to a “logbook, record, or report that is required to be kept, made, or used to show compliance” with a requirement (
                        <E T="03">i.e.,</E>
                         14 CFR 61.48 (currently § 61.59), 63.20, 65.20, and 67.20 (currently § 67.403)). Consistent with those earliest regulations, in 1978, 14 CFR 43.12(a)(1) proscribed fraudulent entries “in any record or report that is required to be kept, made, or used to show compliance” with a requirement. In 1992, the FAA continued applying the distinction between statements and entries when it issued 14 CFR 21.2.
                    </P>
                    <P>
                        The clear dichotomy was blurred when the agency proscribed statements in connection with falsifying both applications and records or reports that are kept, made, or used to show compliance (
                        <E T="03">i.e.,</E>
                         14 CFR 21.2, as amended in 2009; 60.33 (2006); 121.9 (2013); and 111.35 (2021)). Conversely, in 14 CFR 145.12 (2014), the agency proscribed entries in connection with falsifying both applications and records and reports. However, during the same period, the FAA issued other falsification regulations that retained the dichotomy in the earliest falsification regulations (
                        <E T="03">i.e.,</E>
                         14 CFR 120.103 (2004); § 120.213 (2004); and § 139.115 (2013)).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         A false statement is “material” if it has the natural tendency to influence or is capable of influencing an agency decision. 
                        <E T="03">Cassis</E>
                         v. 
                        <E T="03">Helms,</E>
                         737 F.2d 545, 547 (6th Cir. 1984).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See, Pence</E>
                         v. 
                        <E T="03">United States,</E>
                         316 U.S. 332, 338 (1942); 
                        <E T="03">Hart</E>
                         v. 
                        <E T="03">McLucas,</E>
                         535 F.2d 516, 519 (9th Cir. 1976).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Pence, 316 U.S. at 338.
                    </P>
                </FTNT>
                <P>
                    Reproductions for a fraudulent purpose and alterations, including alterations for a fraudulent purpose, are proscribed in falsification regulations. Most of the existing falsification regulations already prohibit reproductions and alterations. Such prohibitions are found at 14 CFR 21.2(a)(3)-(4), 43.12(a)(2)-(3), 60.33(a)(3), 61.59(a)(3)-(4), 63.20(a)(3)-(4), 65.20(a)(3)-(4), 67.403(a)(3)-(4), 89.5(a)(3), 107.5(a)(2), 120.103(e)(3), 139.115(a)(3)-(4), and 145.12(a)(2)-(3). While some of these regulations prohibit any alteration of the applicable document (
                    <E T="03">i.e.,</E>
                     14 CFR 21.2(a)(4), 61.59(a)(4), 65.20(a)(4), and 67.403(a)(4)), others prohibit only fraudulent alterations of the applicable document (
                    <E T="03">i.e.,</E>
                     14 CFR 43.12(a)(3), 60.33(a)(3), and 107.5(a)(2)).
                </P>
                <P>
                    Knowingly omitting or causing to be omitted a material fact results when a person knew that they failed to include the material fact in the document at 
                    <PRTPAGE P="8562"/>
                    issue.
                    <SU>5</SU>
                    <FTREF/>
                     The prohibition of known material omissions is currently found in (1) 14 CFR 89.5(b)(1)-(2) and 145.12(b)(1)-(2) (knowingly concealing or causing to be concealed, by omission, a material fact); (2) 14 CFR 60.33(a)(2) and 121.9(a)(2) (known omissions); and (3) 14 CFR 111.35(a)-(c) (concealing or causing to be concealed a material fact).
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         The FAA prohibited knowingly concealing or causing to be concealed a material fact by omission in the 2014 amendments to 14 CFR part 145. 
                        <E T="03">See</E>
                         14 CFR 145.12(b)(1)-(2). In the preamble of the final rule, the agency explained that a known omission under § 145.12(b)(1)-(2) “is triggered when a person knew that they failed to include the material fact in the document at issue.” 79 FR 46979 (Aug. 12, 2014).
                    </P>
                </FTNT>
                <P>
                    Misleading statements are prohibited by 14 CFR 21.2(a)(1)-(2). The agency previously stated that for purposes of that section, “a misleading statement requires a material representation or omission [
                    <E T="03">i.e.,</E>
                     within the statement] that is likely to mislead a person when that person is acting with reasonable diligence under the circumstances.” 
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         74 FR 53377 (Oct. 16, 2009) (preamble of the final rule amending 14 CFR part 21).
                    </P>
                </FTNT>
                <P>
                    Willful false statements are referenced in 14 CFR 413.17(c). Generally, for a false statement to be “willful,” it must be made deliberately and with knowledge.
                    <SU>7</SU>
                    <FTREF/>
                     Section 413.17(c) adds that such statements are punishable under 18 U.S.C. 1001 and by administrative sanction in accordance with 14 CFR part 405.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See, generally, McClanahan</E>
                         v. 
                        <E T="03">United States,</E>
                         230 F.2d 919, 924 (5th Cir. 1956) (in a prosecution under 18 U.S.C. 1001 in connection with fraudulent mortgage loan applications, the judge appropriately instructed the jury that the word “willful” refers to a forbidden act that is done deliberately and with knowledge).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Current Falsification Regulation Sanction Provisions and Locations in 14 CFR</HD>
                <P>
                    As discussed in the section of this NPRM titled “Authority for this Rulemaking,” the FAA has statutory authority to take certificate action or civil penalty action for falsification regulation violations. In many parts of 14 CFR chapter I that contain falsification regulations, the FAA has elected to set forth sanction consequences for violating a falsification regulation (
                    <E T="03">i.e.,</E>
                     14 CFR 21.2(b); 43.12(b); 60.33(b)-(c); 61.59(b); 63.20(b); 65.20(b); 67.403(b)-(c); 89.5(c); 107.5(b); 121.9(b); 139.115(b); 142.11(e)(3); and 145.12(c)). Other falsification regulations contain no sanction provision (
                    <E T="03">i.e.,</E>
                     14 CFR 111.35, 120.103(e), and 120.213). The falsification regulations that contain sanction provisions lack consistency, as discussed in the “Statement of the Problem” section of this NPRM. Section 413.17(c) of title 14, chapter III, provides that willful false statements are punishable by fine and imprisonment and could result in “administrative sanctions.” 
                    <SU>8</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         In 14 CFR 413.17(c), willful false statements made in any application or document relating to an application, license, or permit are subject to administrative sanctions in accordance with 14 CFR part 405. In 2001, the FAA removed the civil penalty provisions from part 405 and added them to part 406. The FAA, however, inadvertently did not amend § 413.17(c) to reflect the recodification of the civil penalty provisions in part 406. This proposed rulemaking will restore the FAA's ability to assess civil penalties for violations of the falsification regulations in proposed part 402.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Statement of the Problem</HD>
                <P>
                    The FAA implemented the first of its falsification regulations in 1965.
                    <SU>9</SU>
                    <FTREF/>
                     Since then, the agency has implemented various falsification regulations, most recently in 2021. The piecemeal publication of falsification regulations has contributed to two issues that this proposal seeks to remedy: (1) the type of conduct proscribed by the falsification regulations and prescribed sanctions referenced in the various falsification regulations are not consistent across the existing falsification regulations; and (2) many 14 CFR parts lack a falsification prohibition but warrant one.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         The Civil Aeronautics Act of 1938 (Act of 1938) provided criminal penalties for falsification of records by “[a]ny air carrier, or any officer, agent, employee, or representative thereof . . . .” Act of 1938, § 902(e) (1938). However, the Act of 1938 authorized no administrative sanction for falsification, and the Civil Aviation Regulations (CARs) implemented under the Act of 1938 contained no falsification regulations. 
                    </P>
                    <P>
                        Under the Federal Aviation Act of 1958, the Federal Aviation Agency issued an NPRM in 1964 acknowledging the absence of falsification proscriptions in its regulations. The FAA stated that it was “considering amending Parts 61, 63, 65, 67, and 143 [New] of the Federal Aviation Regulations to prohibit cheating on FAA written tests, falsifying applications for airman certificates, logbooks, records, or reports, or unauthorized reproducing or altering certificates or ratings.” 29 FR 4919 (Apr. 8, 1964). The FAA explained that “it has been unable to take appropriate corrective action” against those who cheat on written tests. 
                        <E T="03">Id.</E>
                         at 4920. The FAA continued, “[t]his was due to the absence in the regulations of a specific prohibition of the conduct involved in the particular case. Therefore, it is proposed to adopt regulations that will prohibit cheating activities in connection with written tests for airman certificate or ratings, or the falsification of applications for airman certificates, logbooks, records, and reports used to show compliance with the requirements for the certificates or ratings, or unauthorized reproduction or alteration of certificates or ratings.” 
                        <E T="03">Id.</E>
                         These first falsification regulations became effective March 20, 1965. 30 FR 2195 (Feb. 18, 1965).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">1. Inconsistencies in the Proscribed Conduct and Authorized Sanctions Under the Falsification Regulations</HD>
                <P>
                    The type of activity proscribed as falsification-related conduct and sanction options for such conduct are not consistent across the existing falsification regulations. The agency issued the earliest falsification regulations in title 14 chapter I between 1965 and 1978. The FAA directed 14 CFR 61.48 (1965), 63.20 (1965), and 65.20 (1965) at the conduct of individuals.
                    <SU>10</SU>
                    <FTREF/>
                     These regulations generally prohibited individuals from making intentionally false or fraudulent statements or entries, reproductions for a fraudulent purpose, or alterations in applications or documents that are kept, made, or used to show compliance with a regulatory requirement specific to the part where the particular falsification regulation was published. The sanction provisions in §§ 61.48, 63.20, and 65.20 were consistent in the context of sanction: Each served as a basis for the suspension or revocation of “any” airman or ground instructor certificate or rating.
                    <SU>11</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         On February 1, 1973, the falsification regulation at 14 CFR 61.48 was recodified at § 61.59 as part of the FAA's amendments to parts 61 and 91. 38 FR 3168 (Feb. 1, 1973).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         Section 61.59(b) specifies “any airman certificate, rating, or authorization held by that person.” Sections 63.20(b) and 65.20(b) specify “any airman or ground instructor certificate or rating held by that person.” Although a ground instructor certificate is not an airman certificate as defined by statute or regulation, it is a type of authorization issued under part 61.
                    </P>
                </FTNT>
                <P>
                    Section 67.20 (1965), amended and recodified at § 67.403, prohibited individuals from making intentional false or fraudulent statements, reproductions for a fraudulent purpose, or alterations in connection with applications for FAA medical certification.
                    <SU>12</SU>
                    <FTREF/>
                     Such violation conduct formed a basis for suspending or revoking “all” airman, ground instructor, and medical certificates and ratings held by that person. In addition, unlike the falsification regulations referenced in the preceding paragraph, § 67.403 provided for certificate denials (which, in the context of part 67, involved the denial of an application for a medical certificate).
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         The FAA issued 14 CFR 67.20 in 1965. 30 FR 2197 (Feb. 18, 1965). On March 19, 1996, the FAA amended § 67.20 and renumbered it as 14 CFR 67.403 as part of its revisions to airman medical standards and medical certification procedures. 61 FR 11238 (Mar. 19, 1996).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         Also, § 67.403(b) specified consequences that are unique to the medical certification process in part 67, namely, that falsification is a basis for denying all requests for an Authorization for Special Issuance of a Medical Certificate (Authorization) or Statement of Demonstrated Ability (SODA). Section 67.403(b) also provides for the withdrawal of an Authorization or SODA as a consequence of intentional falsification, fraud, or an alteration.
                    </P>
                </FTNT>
                <P>
                    The FAA issued 14 CFR 43.12 (1978) to proscribe individuals or entities from making fraudulent entries and reproductions and alterations for a 
                    <PRTPAGE P="8563"/>
                    fraudulent purpose in documents kept, made, or used to show compliance with a regulatory requirement specific to part 43.
                    <SU>14</SU>
                    <FTREF/>
                     In 1982, the FAA amended § 43.12(a)(1) to include intentionally false entries.
                    <SU>15</SU>
                    <FTREF/>
                     In contrast to §§ 61.59, 63.20, and 65.20, sanction in the context of a § 43.12 violation was limited to suspension or revocation of “the applicable” certificate (
                    <E T="03">i.e.,</E>
                     the certificate used during the commission of the violation conduct, which most frequently is a mechanic certificate issued under part 65.) 
                    <SU>16</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         43 FR 22639 (May 25, 1978).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         47 FR 41085 (Sept. 16, 1982).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         Section 43.12(b) specifies, “the applicable airman, operator, or production certificate, Technical Standard Order Authorization, FAA-Parts Manufacturer Approval, or Product and Process Specification.”
                    </P>
                </FTNT>
                <P>
                    In 1992, the FAA implemented 14 CFR 21.2 to address falsification-related conduct in the context of certification procedures for products and articles.
                    <SU>17</SU>
                    <FTREF/>
                     The agency explained that § 21.2 “was modeled after similar provisions found in [Federal Aviation Regulations] parts 43, 61, 63, 65, and 143 for certificates, authorizations, and ratings issued under those parts.” 
                    <SU>18</SU>
                    <FTREF/>
                     Thus, § 21.2 was similar to the predecessor falsification regulations insofar as proscribing intentionally false and fraudulent statements, reproductions for a fraudulent purpose, and alterations. In 2009, the FAA amended § 21.2(a)(1)-(2) by proscribing misleading statements.
                    <SU>19</SU>
                    <FTREF/>
                     At that time, the FAA specified that § 21.2 applied to both entities and individuals.
                    <SU>20</SU>
                    <FTREF/>
                     Section 21.2 became inconsistent with the predecessor falsification regulations to the extent that it proscribed misleading statements while the predecessor falsification regulations did not.
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         57 FR 41366 (Sept. 9, 1992).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         57 FR 41366.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         74 FR 53368 (Oct. 16, 2009).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         In the preamble to the final rule amending the part 21 certification procedures and adding the falsification prohibition, the FAA noted that the rule could apply to entities and individuals. 
                        <E T="03">See</E>
                         74 FR 53381 (Oct. 16, 2009) (“This rule primarily directly affects all type certificate (TC) and production approval holders (PAHs), including holders of PCs, TSOs, and PMAs. Regional air cargo carriers and exporters of used aircraft and used engines, propellers, and other articles (primarily distributors and individuals) are also directly affected by this rule.”).
                    </P>
                </FTNT>
                <P>
                    Regarding sanction, § 21.2 was consistent with the predecessor regulations in that it provided for the suspension or revocation of certificates. In addition, § 21.2 also prescribed the suspension or revocation of approvals. The 2009 amendments to § 21.2 made it consistent with § 67.403 by including a provision specifying that falsification is a basis for denying issuance of any certificate or approval under part 21.
                    <SU>21</SU>
                    <FTREF/>
                     However, the sanction in § 21.2 limited the scope of affected certificates. While the sanction in the predecessor falsification regulations affected “any” airman or ground instructor certificate (§§ 61.59, 63.20, and 65.20), or airman, ground instructor, and medical certificates (§ 67.403), 14 CFR 21.2 limited the falsification sanction of suspension or revocation to certificates or approvals issued under “this part.” 
                    <SU>22</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         14 CFR 21.2(b)(1) (74 FR 53368).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         14 CFR 21.2(b)(2)
                    </P>
                </FTNT>
                <P>
                    Inconsistencies continued to emerge in falsification regulations issued or amended by the agency after § 21.2. For example, in 14 CFR 142.11(e)(3) (1996), the agency deviated from prior falsification regulations by proscribing “incomplete,” “inaccurate,” or “false information” (and not “intentionally false information”).
                    <SU>23</SU>
                    <FTREF/>
                     Consistent with the limited scope of affected certificates under §§ 21.2 and 43.12, but inconsistent with the broader scope under other predecessor falsification regulations, § 142.11(e)(3) affected certificates issued under “this part,” (
                    <E T="03">i.e.,</E>
                     14 CFR part 142).
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         Section 142.11(e)(3) provides: “The Administrator may deny, suspend, revoke, or terminate a certificate under this part if the Administrator finds that the applicant or the certificate holder . . . (3) Has provided incomplete, inaccurate, fraudulent, or false information for a training center certificate . . . .”
                    </P>
                </FTNT>
                <P>
                    Also, in 1996, the FAA amended the falsification regulations in 14 CFR part 67 to broaden the regulatory basis for action by proscribing the provision of incorrect statements or entries by an applicant or airman when applying for medical certification.
                    <SU>24</SU>
                    <FTREF/>
                     However, the agency did not amend other falsification regulations that existed prior to 1996 to add an incorrect statement or entry provision. In 2006, the FAA proscribed incorrect statements and entries in 14 CFR 60.33.
                    <SU>25</SU>
                    <FTREF/>
                     Following the publication of § 60.33, however, the FAA did not amend existing regulations to address incorrect statements and entries. It also did not add prohibitions against incorrect statements and entries in the subsequent falsification regulations in 14 CFR parts 89, 107, 111, 121, 139, and 145.
                </P>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         61 FR 11251 (Mar. 19, 1996).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         71 FR 63426 (Oct. 30, 2006).
                    </P>
                </FTNT>
                <P>
                    The FAA specified different sanctions in proscribing incorrect statements or entries in §§ 67.403(c) and 60.33 and incomplete, inaccurate, and false information in § 142.11(e)(3). The sanction in § 67.403(c) limits the scope of affected certificates to the medical certificate, authorization, or statement of demonstrated ability at issue rather than “all” certificates as under § 67.403(b) for other falsification-related conduct under part 67. Under 14 CFR 60.33, the sanction for an incorrect statement or entry on which the FAA relied is removal of Flight Simulation Training Device (FSTD) qualification, including the withdrawal of approval for use of an FSTD or denying an application for a qualification.
                    <SU>26</SU>
                    <FTREF/>
                     As to the provision of “incomplete,” “inaccurate,” or “false information” referenced in § 142.11(e)(3), the regulation authorizes the denial, suspension, revocation, or termination of a part 142 certificate.
                </P>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         14 CFR 60.33(c).
                    </P>
                </FTNT>
                <P>
                    In 2004, the FAA added falsification provisions to the industry drug and alcohol testing regulations, which, at that time, were located at 14 CFR part 121, appendices I and J. Effective July 13, 2009, the FAA's drug and alcohol testing regulations were recodified, without substantive change, at 14 CFR 120.103(e) and 120.213.
                    <SU>27</SU>
                    <FTREF/>
                     (These regulations will hereinafter be referred to as §§ 120.103(e) and 120.213.) Sections 120.103(e) and 120.213 are limited to proscribing intentional falsification and fraud, and reproductions and alterations for a fraudulent purpose, regarding applications for alcohol and drug testing programs, and reports or records required under those programs. These sections contain no sanction provisions.
                </P>
                <FTNT>
                    <P>
                        <SU>27</SU>
                         
                        <E T="03">See</E>
                         74 FR 22649 (May 14, 2009).
                    </P>
                </FTNT>
                <P>
                    The falsification proscriptions in the more recent falsification regulations (
                    <E T="03">i.e.,</E>
                     14 CFR 89.5 (2021), 107.5 (2016), 111.35 (2021), 121.9 (2013), 139.115 (2013), and 145.12 (2014)) similarly lack consistency in describing the scope of conduct. Sections 107.5 and 139.115 proscribe intentional falsification, fraud, reproductions for a fraudulent purpose, and alterations for a fraudulent purpose. Sections 89.5 and 145.12 contain those same proscriptions and also proscribe knowingly concealing or causing to be concealed, by omission, a material fact. Sections 111.35 and 121.9, while proscribing intentional falsification and fraud, do not proscribe reproductions and alterations. Section 111.35, similar to §§ 89.5 and 145.12, proscribes concealing or causing to be concealed a material fact. However, § 111.35 lacks the knowledge element and “omission” terminology that is present in §§ 89.5 and 145.12. Section 121.9 proscribes “known omissions.”
                </P>
                <P>
                    In the context of sanction provisions, 14 CFR 89.5, 107.5, 111.35, 121.9, 139.115, and 145.12 are largely inconsistent. Section 111.35 contains no sanction provision. The sanction provisions in §§ 89.5, 107.5, 121.9, 
                    <PRTPAGE P="8564"/>
                    139.115, and 145.12 vary in consistency. Section 139.115 provides for suspension or revocation but does not provide for a civil penalty. Meanwhile, §§ 89.5, 107.5, 121.9, and 145.12 authorize suspension or revocation, civil penalty, and denial of an application.
                    <SU>28</SU>
                    <FTREF/>
                     Yet, the reach of suspensions, revocations, and denials vary among §§ 89.5, 107.5, 121.9, 139.115, and 145.12. Section 107.5(b) provides for suspension or revocation of “any certificate, waiver, or declaration of compliance issued or accepted by the Administrator under this part and held by that person . . . ” and the denial of any application for a remote pilot certificate or certificate of waiver and declaration of compliance. Section 121.9 applies the suspension or revocation to “any certificate held by that person that was issued under this chapter” (
                    <E T="03">i.e.,</E>
                     14 CFR parts 1-199) and the denial of an application for any approval under this part. Section 139.115(b) provides for suspension or revocation of “any certificate or approval under this part and held by that certificate holder and any other certificate issued under this title” (
                    <E T="03">i.e.,</E>
                     14 CFR) but does not provide for a denial of an application. Section 145.12 allows the FAA to suspend or revoke “the repair station certificate and any certificate, approval, or authorization issued by the FAA and held by that person” and the denial of an application under part 145.
                </P>
                <FTNT>
                    <P>
                        <SU>28</SU>
                         In 2021, the FAA amended 14 CFR 107.5 to include the denial of a declaration of compliance as a sanction for falsification. 86 FR 4381 (Jan. 15, 2021).
                    </P>
                </FTNT>
                <P>In § 89.5, the FAA articulated a broader approach to sanction. Under § 89.5(c), falsification is a basis for “[d]enial, suspension, rescission, or revocation of any acceptance, application, approval, authorization, certificate, declaration, declaration of compliance, designation, document, filing, qualification, means of compliance, record, report, request for reconsideration, or similar instrument granted by the Administrator and held by that person” or a civil penalty.</P>
                <P>
                    Regarding 14 CFR chapter III, 14 CFR 413.17(c) is the sole falsification regulation. It references only willful false statements and thus is limited in its application. It cites criminal sanctions under 18 U.S.C. 1001. It also provides that willful false statements may result in “administrative sanctions in accordance with part 405 of this chapter.” 
                    <SU>29</SU>
                    <FTREF/>
                     Although the removal of § 413.17(c) would remove the reference to 18 U.S.C. 1001, this does not imply that 18 U.S.C. 1001 is inapplicable to false statements submitted to the FAA, nor does it restrict the FAA's ability to refer possible criminal violations of 18 U.S.C. 1001 to the DOT Office of the Inspector General or the Department of Justice. Intentionally false statements currently covered by 14 CFR chapter I and the proposed 14 CFR 3.403 and 402.3 may still be subject to 18 U.S.C. 1001. However, FAA regulations do not generally refer to possible criminal consequences, and the FAA does not believe that the regulations should specifically mention 18 U.S.C. 1001.
                </P>
                <FTNT>
                    <P>
                        <SU>29</SU>
                         
                        <E T="03">See</E>
                         note 6, 
                        <E T="03">supra,</E>
                         regarding the removal of the civil penalty prescription from part 405.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Incomplete Application of the Falsification Regulations</HD>
                <P>Many parts of 14 CFR chapter I lack a falsification regulation but warrant one. In the absence of such falsification regulations, the FAA is precluded from taking enforcement action for falsification-related conduct under those parts. As a result, there is no general or specific deterrent for those who might engage in such conduct. For example, the falsification regulation in part 121 applying to domestic, flag, and supplemental operations currently has no counterpart in part 135 pertaining to commuter and on-demand operations despite that both parts authorize commercial operations. Similarly, the falsification regulation in part 142 applying to training centers has no counterpart in part 141 or part 147. Part 47, which relates to aircraft registration, also contains no falsification prohibition despite instances of falsified aircraft registration applications.</P>
                <P>
                    Similarly, most of 14 CFR chapter III lacks falsification regulations but warrants them. In 14 CFR chapter III, only a single falsification regulation (
                    <E T="03">i.e.,</E>
                     § 413.17(c)) exists. It addresses only willful false statements in the context of applications and documents relating to applications, licenses, or permits. Although some regulations in 14 CFR chapter III require licensees to ensure the continuing accuracy of representations contained in their application (
                    <E T="03">i.e.,</E>
                     §§ 413.7(c), 414.13(d), 414.21, 414.27, 417.11, 431.73(a), and 450.211(a)), those regulations do not provide a comprehensive falsification prohibition.
                </P>
                <P>
                    Table 1 sets forth a brief history of the falsification regulations, including prohibitions and sanction for the year each regulation was implemented.
                    <SU>30</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>30</SU>
                         After implementation of the falsification regulations in 14 CFR parts 21 and 43, the FAA made the following amendments. In 1982, the FAA amended 14 CFR 43.12(a)(1) to include intentionally false entries. 47 FR 41085 (Sept. 16, 1982). In 2009, the FAA amended 14 CFR 21.2(a)(1)-(2) by proscribing misleading statements. 74 FR 53368 (Oct. 16, 2009). The 2009 amendments to 14 CFR 21.2 included denying issuance of any certificate or approval under part 21 as a sanction for falsification. 74 FR 53368 (Oct. 16, 2009).
                    </P>
                </FTNT>
                <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="xs36,r50,r100,r100">
                    <TTITLE>Table 1—History of FAA Falsification Regulations</TTITLE>
                    <BOXHD>
                        <CHED H="1">Year</CHED>
                        <CHED H="1">Part(s)/section(s)</CHED>
                        <CHED H="1">Prohibited conduct</CHED>
                        <CHED H="1">Sanction</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1965</ENT>
                        <ENT>61.48 (presently codified at §§ 61.59), 63.20, 65.20</ENT>
                        <ENT>Fraudulent or intentionally false statements and entries, reproductions for a fraudulent purpose, and alterations involving documents and records associated with parts 61, 63, and 65, respectively</ENT>
                        <ENT>61.59—Suspending or revoking any airman certificate, rating, or authorization held by that person; 63.20, 65.20—Suspending or revoking any airman or ground instructor certificate or rating held by that person.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1965</ENT>
                        <ENT>67.20 (presently codified at § 67.403)</ENT>
                        <ENT>Fraudulent or intentionally false statements and entries, fraudulent reproductions, alterations, and incorrect statements or entries involving documents and records under part 67</ENT>
                        <ENT>
                            (1) Suspending or revoking all airman, ground instructor, and medical certificates and ratings held by that person;
                            <LI>(2) Withdrawing all Authorizations or SODAs held by that person; and</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>(3) Denying all applications for medical certification and requests for Authorizations or SODAs. An incorrect statement or entry may serve as a basis for suspending or revoking a medical certificate; withdrawing an Authorization or SODA; or denying an application for a medical certificate or request for an authorization or SODA.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8565"/>
                        <ENT I="01">1978</ENT>
                        <ENT>43.12</ENT>
                        <ENT>Fraudulent entries and fraudulent reproductions and alterations involving records or documents associated with part 43</ENT>
                        <ENT>Suspending or revoking the applicable airman, operator, or production certificate, Technical Standard Order Authorization, FAA-Parts Manufacturer Approval, or Product and Process Specification issued by the Administrator and held by that person.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1992</ENT>
                        <ENT>21.2</ENT>
                        <ENT>Fraudulent or intentionally false statements, fraudulent reproductions, and alterations involving documents associated with part 21</ENT>
                        <ENT>Suspending or revoking any certificate or approval issued under part 21 part and held by that person.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1996</ENT>
                        <ENT>142.11(e)(3)</ENT>
                        <ENT>Incomplete, inaccurate, fraudulent, or false information associated with training center certificates</ENT>
                        <ENT>Denial, suspension, revocation, or termination of a certificate under part 142.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2004</ENT>
                        <ENT>120.103(e) and 120.213 (formerly 121 app. I and J)</ENT>
                        <ENT>Fraudulent or intentionally false statements or entries and fraudulent reproduction or alteration involving records and documents associated with part 120</ENT>
                        <ENT>None.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2006</ENT>
                        <ENT>60.33</ENT>
                        <ENT>Fraudulent or intentionally false statements, known omissions, fraudulent reproduction or alteration, and incorrect statements or entries upon which the FAA relied or could have relied involving records or documents associated with part 60</ENT>
                        <ENT>
                            One or any combination of the following:
                            <LI>(1) A civil penalty;</LI>
                            <LI>(2) Suspension or revocation of any certificate held by that person that was issued under 14 CFR chapter I;</LI>
                            <LI>(3) The removal of FSTD qualification and approval for use in a training program.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>An incorrect statement or entry, upon which the FAA relied or could have relied, may serve as the basis for the removal of qualification of an FSTD, including the withdrawal of approval for use of an FSTD or denying an application for a qualification.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2007</ENT>
                        <ENT>413.17(c)</ENT>
                        <ENT>Willful false statements made relating to applications, licenses, and permits</ENT>
                        <ENT>Administrative sanctions in accordance with part 405 of 14 CFR chapter III.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2013</ENT>
                        <ENT>121.9</ENT>
                        <ENT>Fraudulent or intentionally false statements and known omissions involving records and documents under part 121</ENT>
                        <ENT>
                            One or any combination of the following:
                            <LI>(1) A civil penalty;</LI>
                            <LI>(2) Suspension or revocation of any certificate held by that person that was issued under 14 CFR chapter I;</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>
                            (3) The denial of an application for any approval under part 121;
                            <LI>(4) The removal of any approval under part 121.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2013</ENT>
                        <ENT>139.115</ENT>
                        <ENT>Fraudulent or intentionally false statements or entries and fraudulent reproduction or alteration involving records or documents associated with part 139</ENT>
                        <ENT>Suspension or revocation of any certificate or approval issued under part 139 and held by that certificate holder and any other certificate issued under 14 CFR and held by the person committing the act.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2014</ENT>
                        <ENT>145.12</ENT>
                        <ENT>Fraudulent or intentionally false entries, fraudulent reproduction or alteration, and omissions of a material fact involving records or documents associated with part 145</ENT>
                        <ENT>
                            One or any combination of the following:
                            <LI>(1) Suspending or revoking the repair station certificate and any certificate, approval, or authorization issued by the FAA and held by that person;</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>
                            (2) A civil penalty;
                            <LI>(3) The denial of an application under part 145.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2016</ENT>
                        <ENT>107.5</ENT>
                        <ENT>Fraudulent or intentionally false records or reports and fraudulent reproduction or alteration involving records or documents associated with part 107</ENT>
                        <ENT>
                            Any of the following:
                            <LI>(1) Denial of an application for a remote pilot certificate or a certificate of waiver;</LI>
                            <LI>(2) Suspension or revocation of any certificate, waiver, or declaration of compliance issued or accepted by the Administrator under part 107 and held by that person; or</LI>
                            <LI>(3) A civil penalty.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2021</ENT>
                        <ENT>89.5</ENT>
                        <ENT>Fraudulent or intentionally false statements, fraudulent reproduction or alteration, and knowingly concealing or causing to be concealed a material fact involving records or documents associated with part 89</ENT>
                        <ENT>
                            (1) Denial, suspension, rescission, or revocation of any acceptance, application, approval, authorization, certificate, declaration, declaration of compliance, designation, document, filing, qualification, means of compliance, record, report, request for reconsideration, or similar instrument issued or granted by the Administrator and held by that person; or
                            <LI>(2) A civil penalty.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8566"/>
                        <ENT I="01">2021</ENT>
                        <ENT>111.35</ENT>
                        <ENT>Fraudulent or intentionally false statements and concealing or causing to be concealed a material fact involving records or documents associated with part 111</ENT>
                        <ENT>None.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD2">D. Summary of the Costs and Benefits</HD>
                <P>Falsification regulations promote aviation and commercial space safety by incentivizing participants in the National Aerospace System to provide accurate and truthful information in safety-related records. Through the proposed rule, the FAA intends to enhance aviation safety by standardizing the scope of conduct that the FAA intends to deter, proscribed by falsification regulations, across the applicable sections of 14 CFR parts 1 through 199 and 14 CFR parts 413 through 460 and extending this scope of conduct to parts that currently do not have—but should have—falsification provisions. The proposed rule also intends to standardize sanction provisions for this conduct and allow for more consistent sanction determinations as appropriate. The FAA has evaluated the cost impacts to the stakeholders involved in this proposed rulemaking and does not anticipate any new cost impact to the industry or the FAA as a result of this proposed rule.</P>
                <P>The FAA has also determined that this proposed rule is not a “significant regulatory action” as defined in section 3(f) of Executive Order 12866 and is not “significant” as defined in DOT's Regulatory Policies and Procedures.</P>
                <HD SOURCE="HD1">II. Authority for This Rulemaking</HD>
                <P>The FAA's authority to issue rules on 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.</P>
                <P>With respect to 14 CFR chapter I, this rulemaking is issued under 49 U.S.C. 44701(a)(5), which establishes the authority of the Administrator to prescribe regulations and minimum standards for other practices, methods, and procedures the Administrator finds necessary for safety in air commerce and national security. It is also issued under 49 U.S.C. 44702-44709, which prescribe the FAA's authority to issue different types of certificates to various individuals and entities and to amend, modify, suspend, or revoke those certificates as appropriate. This NPRM is within the scope of these sections because it would establish new falsification regulations that consolidate all existing falsification regulations into a general rule that standardizes the existing falsification regulations and ensures that falsification-related conduct that is not, but should be, addressed by current regulations is covered under the general rule. This NPRM also falls within the scope of 49 U.S.C. 46301 since this section authorizes the assessment of civil penalties for noncompliance with the general falsification provision.</P>
                <P>
                    With respect to 14 CFR chapter III, this rulemaking is issued under the authority described in the Commercial Space Launch Act of 1984, as amended and recodified at 51 U.S.C. 50901-50923 (the Act). The Act authorizes DOT to oversee, investigate, license, and regulate commercial launch and reentry activities and the operation of launch and reentry sites as carried out by U.S. citizens or within the United States. 
                    <E T="03">See</E>
                     51 U.S.C. 50904, 50905. The Act directs the DOT to exercise this responsibility consistent with public health and safety, safety of property, and the national security and foreign policy interests of the United States. 
                    <E T="03">See</E>
                     51 U.S.C. 50901. This authority has been delegated to the FAA's Associate Administrator for Commercial Space Transportation. 
                    <E T="03">See</E>
                     14 CFR 401.3.
                </P>
                <P>The proposed regulations fall within the scope of 51 U.S.C. 50901-50923 because they would establish comprehensive falsification proscriptions that currently do not exist in 14 CFR chapter III. They would promote the integrity of the information that the FAA relies on and would serve as a basis for regulatory action as appropriate, which is essential to the FAA's statutory responsibility to promote continuous improvement of commercial space activities and ensure that such activities are consistent with public health and safety, safety of property, and national security and foreign policy interests. The proposed rulemaking is within the scope of 51 U.S.C. 50908, since this section authorizes the FAA, under delegated authority from the Secretary of Transportation, to modify, suspend, or revoke a license issued or transferred under 51 U.S.C. Subtitle V, chapter 509. It is within the scope of 51 U.S.C. 50917 since it authorizes the FAA, under delegated authority from the Secretary of Transportation, to assess a civil penalty for a violation of chapter 509, a regulation prescribed under chapter 509, or any term of a license issued or transferred under chapter 509.</P>
                <HD SOURCE="HD1">III. Discussion of the Proposal</HD>
                <P>The FAA proposes to amend and reorganize the current falsification regulations to create uniform and comprehensive falsification regulations for the applicable parts of 14 CFR chapter I and across 14 CFR chapter III, subchapter C. This proposed rulemaking would standardize the proscribed conduct and expand the proscription to the pertinent parts of 14 CFR chapters I and III as appropriate. It would also standardize sanction provisions.</P>
                <HD SOURCE="HD2">A. Applicability of the Proposed Rulemaking to 14 CFR Chapter I</HD>
                <P>The proposed rulemaking would address the lack of standardization in current falsification regulations across the applicable parts of 14 CFR chapter I. In addition, the proposed rule would ensure that the falsification prohibition applies to the particular parts of 14 CFR chapter I that should have such a prohibition but currently do not. Under proposed § 3.401, the proposed rule would apply to any person subject to the requirements in 14 CFR chapter I, subchapter A (except parts 1 and 3), subchapter C (except part 39), subchapter D, subchapter E (except parts 71 and 73), subchapter F (except parts 95 and 97), subchapter G (except part 110), subchapter H, and part 183 of subchapter K.</P>
                <HD SOURCE="HD3">1. Application of Proposed Rule to 14 CFR Chapter I, Subchapter A (Except Parts 1 and 3)</HD>
                <P>
                    Subchapter A consists of 14 CFR parts 1, 3, and 5. The proposed rule would apply to 14 CFR part 5, which contains recordkeeping requirements regarding Safety Management Systems (SMS) that may be subject to falsification.
                    <SU>31</SU>
                    <FTREF/>
                     The proposed rule would not apply to 14 CFR parts 1 and 3. Part 1 contains definitions and abbreviations. Part 3 
                    <PRTPAGE P="8567"/>
                    currently consists of subparts A and B. Subpart A contains an independent falsification regulation governing statements about products, parts, and appliances, and materials that may be used on a type-certificated product and would remain unaffected by the proposed rule.
                    <SU>32</SU>
                    <FTREF/>
                     Subpart B prescribes security threat disqualification by the FAA following receipt of a notification from the Transportation Security Administration.
                    <SU>33</SU>
                    <FTREF/>
                     The proposed rule would be located in a new subpart D of part 3.
                </P>
                <FTNT>
                    <P>
                        <SU>31</SU>
                         
                        <E T="03">See</E>
                         14 CFR part 5, subpart F (“SMS Documentation and Recordkeeping”), 14 CFR 5.95 and 5.97.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>32</SU>
                         
                        <E T="03">See</E>
                         14 CFR 3.5 (prohibiting falsification regarding products, parts, and appliances).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>33</SU>
                         14 CFR 3.200 and 3.205.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Applicability of Proposed Rule to 14 CFR, Chapter I, Subchapter C (Except Part 39)</HD>
                <P>
                    Subchapter C consists of 14 CFR parts 21, 23, 25, 26, 27, 29, 31, 33, 34, 35, 36, 39, 43, 45, 47, 48, and 49. Existing falsification regulations are in 14 CFR 21.2 and 43.12. The proposed rulemaking would remove those sections and apply the proposed rule to parts 21 and 43. The proposed rule would also apply to 14 CFR parts 23, 25, 26, 27, 29, 31, 33, 34, 35, 36 (
                    <E T="03">i.e.,</E>
                     “airworthiness requirements”) and 14 CFR parts 45, 47, 48, and 49 (
                    <E T="03">i.e.,</E>
                     “registration requirements”).
                </P>
                <P>
                    Section 21.2 addresses falsification of information submitted under part 21 and the airworthiness requirements. A person seeking a certificate or approval, or a change thereto, under part 21 must first show compliance with the airworthiness requirements, as applicable.
                    <SU>34</SU>
                    <FTREF/>
                     The person shows such compliance by, among other things, submitting documentation relating to airworthiness requirements to the FAA. The FAA reviews the documentation and determines whether the person has met the applicable standards before issuing or amending a certificate or approval under part 21. Consequently, if a person falsifies a document and submits it to the FAA to show compliance with the airworthiness requirements in the process of seeking a certificate, approval, or change under 14 CFR part 21, the FAA addresses the falsification under 14 CFR 21.2. Under the proposed rulemaking, the falsification prohibition in subpart D of part 3 would apply directly to the airworthiness requirements in addition to 14 CFR part 21.
                </P>
                <FTNT>
                    <P>
                        <SU>34</SU>
                         Under 14 CFR part 21, the FAA issues and changes design approvals, production approvals, airworthiness certificates, and airworthiness approvals. 14 CFR 21.1(a)(1). Under 14 CFR 21.1(b)(4), a design approval “means a type certificate . . . or the approved design under a PMA, TSO authorization, letter of TSO design approval, or other approved design . . . .” The “Airworthiness Standards” (
                        <E T="03">i.e.,</E>
                         14 CFR parts 23-36) with the exception of part 34, (1) prescribe airworthiness standards for the issue of type certificates and changes to certificates and (2) require each person who applies under part 21 for such a certificate or change to show compliance with the applicable requirements of those parts. 
                        <E T="03">See</E>
                         14 CFR 23.2000(a), 25.1(a)-(b), 26.1(a)-(b), 27.1(a)-(b), 29.1(a) and (g), 31.1(a)-(b), 33.1(a)-(b), 35.1(a)-(b), and 36.1(a)-(c). Part 34 sets forth fuel venting and exhaust emission requirements for turbine powered airplanes.
                    </P>
                </FTNT>
                <P>The proposed rule would also apply to the registration requirements in 14 CFR parts 45, 47, 48, and 49. Parts 45, 47, 48, and 49 contain record requirements that may be subject to falsification. Due to the absence of a falsification regulation in part 47, the FAA has lacked a direct approach to addressing registration falsifications under that part. Hence, the proposed rulemaking would appropriately apply to parts 45, 47, 48, and 49.</P>
                <P>The proposed rule would not apply to 14 CFR part 39 since it provides a legal framework for the FAA's system of airworthiness directives. It does not contain requirements that are subject to falsification.</P>
                <HD SOURCE="HD3">3. Applicability of Proposed Rule to 14 CFR, Chapter I, Subchapter D</HD>
                <P>
                    Subchapter D (“Airmen”) consists of 14 CFR parts 60, 61, 63, 65, 67, and 68. Existing falsification regulations are in 14 CFR 60.33, 61.59, 63.20, 65.20, and 67.403. The proposed rulemaking would remove those sections and apply to parts 60, 61, 63, 65, and 67. The proposed rule would also apply to part 68, which does not have an existing falsification regulation.
                    <SU>35</SU>
                    <FTREF/>
                     Part 68 requires an individual to make representations, provide them to the FAA, and retain required documents in their logbook. Since these record requirements could be subject to falsification, the proposed rule would apply to part 68.
                </P>
                <FTNT>
                    <P>
                        <SU>35</SU>
                         Part 68 requires an individual to complete a medical education course (§ 68.3) and a comprehensive medical evaluation (14 CFR 68.5), which includes a comprehensive medical examination checklist (CMEC). The individual makes required representations on the medical education course information (§§ 68.3(b)(1), (3)-(5)), which is submitted to the FAA (§ 68.3(b)) and the CMEC (§ 68.7(a)(2)). Both the medical education course completion certificate and the CMEC must be kept in the individual's logbook. (§ 68.3(b)(1) and 61.113(i)(3)).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">4. Applicability of Proposed Rule to 14 CFR, Chapter I, Subchapter E (Except Parts 71 and 73)</HD>
                <P>
                    Subchapter E (“Airspace”) consists of 14 CFR parts 71, 73, and 77, none of which contain existing falsification regulations. The proposed rulemaking would apply only to part 77 since that part requires an individual to submit documentation to the FAA that could be subject to falsification.
                    <SU>36</SU>
                    <FTREF/>
                     In contrast, parts 71 and 73 consist of FAA designations of airspace. Those parts are not subject to falsification.
                </P>
                <FTNT>
                    <P>
                        <SU>36</SU>
                         Part 77 establishes, among other things, “the requirements to provide notice to the FAA of certain proposed construction, or the alteration of existing structures” and “[t]he process to petition the FAA for discretionary review of determinations, revisions, and extensions of determinations.” 14 CFR 77.1(a) and (d). Sections 77.7, 77.9, and 77.11 describe the contents of such notices provided to the FAA. Following submission of the notice(s), “[t]he FAA will make a determination stating whether the proposed construction or alteration would be a hazard to air navigation, and will advise all known interested persons.” 14 CFR 77.31(a).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">5. Applicability of Proposed Rule to 14 CFR Chapter I, Subchapter F (Except Parts 95 and 97) </HD>
                <P>
                    Subchapter F (“Air Traffic and General Operating Rules”) consists of 14 CFR parts 89, 91, 93, 95, 97, 99, 101, 103, 105, and 107. Existing falsification regulations are in 14 CFR 89.5 and 107.5. The proposed rulemaking would remove these sections and apply the proposed rule to parts 89 and 107. The proposed rule would also apply to 14 CFR parts 91, 93, 99, 101, 103, and 105. These parts contain requirements for applying for certificates, waivers, and other issuances or grants or for keeping or making records.
                    <SU>37</SU>
                    <FTREF/>
                     Since these documentary requirements are subject to falsification, the proposed rule would apply. The proposed rule would not apply to 14 CFR parts 95 and 97 since 
                    <PRTPAGE P="8568"/>
                    they consist of FAA airspace and procedure designations. They do not contain documentation requirements subject to falsification.
                </P>
                <FTNT>
                    <P>
                        <SU>37</SU>
                         The following are examples of such requirements. 
                    </P>
                    <P>
                        Part 91—Subpart K of part 91 contains requirements for submitting an application for management specifications (14 CFR 91.1014) and for recordkeeping (14 CFR 91.1027). 
                        <E T="03">See also,</E>
                         14 CFR 91.903(b) (application for a certificate of waiver) and 91.871 (waivers from interim compliance requirements).
                    </P>
                    <P>Part 93—Section 93.325 requires that “[e]ach certificate holder must submit in writing, within 30 days of the end of each calendar quarter, the total number of commercial [Special Flight Rules Area] SFRA [Washington, DC Metropolitan Area Special Flight Rules Area] operations conducted for that quarter.” Section 93.323 requires a certificate holder to file a visual flight rules flight plan before conducting a commercial SFRA operations. </P>
                    <P>Part 99—Section 99.9(b)(1) provides that, “[n]o person may operate an aircraft into, within, or whose departure point is within an ADIZ unless—(1) The person files a DVFR flight plan containing the time and point of ADIZ penetration . . . .”</P>
                    <P>Part 101—Part 101 specifies the required contents of a notification to the FAA by a person who intends to operate an unshielded moored balloon or kite (14 CFR 101.15) or an unmanned free balloon (14 CFR 101.37).</P>
                    <P>Part 103—Section 103.3(b) requires the pilot or operator of an ultralight vehicle to, upon request of the Administrator, furnish satisfactory evidence that the vehicle is subject only to the provisions of part 103. </P>
                    <P>Part 105—Section 105.15(a) requires a person requesting an authorization to conduct a parachute operation over or into a congested area to submit a notification consisting of particular information.</P>
                </FTNT>
                <HD SOURCE="HD3">6. Applicability of Proposed Rule to 14 CFR Chapter I, Subchapter G (Except Part 110) </HD>
                <P>Subchapter G (“Air Carriers and Operators for Compensation or Hire: Certification and Operations”) consists of 14 CFR parts 110, 111, 117, 119, 120, 121, 125, 129, 133, 135, 136, 137, and 139. Existing falsification regulations are contained in 14 CFR 111.35, 120.103(e), 120.213, 121.9, and 139.115. The proposed action would remove those sections and apply the proposed rule to parts 111, 120, 121, and 139.</P>
                <P>
                    The proposed rule would also apply to 14 CFR parts 117, 119, 125, 129, 133, 135, 136, and 137, none of which contain an existing falsification regulation. Part 117 contains reporting requirements that may be subject to falsification, prompting the necessity for the application of the proposed rulemaking.
                    <SU>38</SU>
                    <FTREF/>
                     Although parts 119, 121, 125, 129, 133, 135, 136, and 137 require documents that are subject to falsification, only part 121 contains a falsification regulation. Accordingly, the proposed rulemaking would apply to those sections. The proposed action would not apply to 14 CFR part 110, as this part provides definitions only.
                </P>
                <FTNT>
                    <P>
                        <SU>38</SU>
                         
                        <E T="03">See</E>
                         14 CFR 117.11(c) (“Each certificate holder must report to the administrator within 10 days any flight time that exceeded the maximum flight time limits permitted by this section or § 117.23(b).”)
                    </P>
                </FTNT>
                <HD SOURCE="HD3">7. Applicability of Proposed Rule to 14 CFR Chapter I, Subchapter H </HD>
                <P>Subchapter H (“Schools and Other Certificated Agencies”) consists of 14 CFR parts 141, 142, 145, and 147. Existing falsification regulations are in 14 CFR 142.11(e) and 145.12. The proposed action would remove those sections and apply the proposed rule to parts 142 and 145. The proposed rule would also apply to parts 141 and 147 since these parts have documentation requirements that may be subject to falsification. Part 142 contains operation and certification requirements and a falsification regulation, yet parts 141 and 147 do not proscribe falsification despite containing analogous operation and certification requirements in the context of aviation training.</P>
                <HD SOURCE="HD3">8. Applicability of Proposed Rule to 14 CFR Chapter I, Subchapter K, Part 183 </HD>
                <P>
                    Subchapter K (“Administrative Regulations”) consists of 14 CFR parts 183, 185, 187, 189, and 193. Subchapter K contains no existing falsification regulations. The proposed rulemaking would apply solely to 14 CFR part 183 as parts 185, 187, 189, and 193 do not contain provisions subject to falsification.
                    <SU>39</SU>
                    <FTREF/>
                     Generally, intentional falsification by a delegee under part 183 would likely result in the FAA rescinding the delegation under 49 U.S.C. 44702(d)(2).
                    <SU>40</SU>
                    <FTREF/>
                     Under the proposed rule, the FAA would have the option of initiating an action against a delegee for intentional falsification, and it would be “a basis for . . . rescinding . . . any . . . designation.” 
                    <SU>41</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>39</SU>
                         Part 183 “describes the requirements for designating private persons to act as representatives of the Administrator in examining, inspecting, and testing persons and aircraft for the purpose of issuing airman, operating, and aircraft certificates. In addition, this part states the privileges of those representatives and prescribes rules for the exercising of those privileges, as follows: 
                    </P>
                    <P>(a) An individual may be designated as a representative of the Administrator under subparts B or C of this part. </P>
                    <P>(b) An organization may be designated as a representative of the Administrator by obtaining an Organization Designation Authorization under subpart D of this part.” 14 CFR 183.1(a)-(b).</P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>40</SU>
                         
                        <E T="03">See</E>
                         49 U.S.C. 44702(d)(2) (authorizing the FAA to “rescind a delegation under this subsection at any time for any reason the Administrator considers appropriate.”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>41</SU>
                         Sections 3.403(d)(1) and 3.405(b) of the proposed rule.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">9. Other Subchapters of 14 CFR Chapter I to Which the Proposed Rule Would Not Apply</HD>
                <P>The proposed rulemaking would not apply to 14 CFR chapter I, subchapters B (“Procedural Rules”); I (“Airports”); J (“Navigational Facilities”); and N (“War Risk Insurance”). The application of the proposed rule to these subchapters would constitute an unnecessary or unwarranted expansion of the falsification prohibition at this time.</P>
                <HD SOURCE="HD2">B. Applicability of the Proposed Rulemaking to 14 CFR Chapter III</HD>
                <P>The proposed rulemaking would address the lack of comprehensive falsification regulations across the applicable parts of 14 CFR chapter III by creating a new part 402, entitled “General Requirements and Falsification Prohibitions.” The proposed rule in part 402 would parallel the proposed rule in part 3, subpart D. It would apply to any person subject to the requirements in subchapter C of 14 CFR chapter III.</P>
                <P>
                    Subchapter C (“Licensing”) consists of 14 CFR parts 413, 414, 415, 417, 420, 431, 433, 435, 437, 440, 450, and 460. Subchapter C currently has one falsification regulation in subchapter C, which is located at 14 CFR 413.17(c) (“Continuing Accuracy of Application; Supplemental Information; Amendment”). The proposed rulemaking would remove that subparagraph and would apply the proposed rule in new part 402 to all parts of subchapter C. Subchapter C contains myriad requirements and procedures in connection with licenses, approvals, permits, and recordkeeping, and for demonstrating financial responsibility. The requirements involve submission of information to the FAA that could be subject to falsification.
                    <SU>42</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>42</SU>
                         
                        <E T="03">See</E>
                         requirements in 14 CFR 413.7 (an application for a license); 414.13 (an application for a safety approval); 415.13 (transfer of a launch license); 417.15 and 420.61 (maintaining all records necessary to verify that the operator conducts its operations in accordance with representations contained in its application); 431.25 (an application for a policy review); 433.3 (issuance of a license to operate a reentry site); 435.5 (obtaining policy and safety approvals concerning reentry of a reentry vehicle other than a reusable launch vehicle); 437.21 (obtaining an Experimental Permit); 440.15 (submitting to the FAA evidence of financial responsibility and compliance with allocation of risk requirements under part 440); 450.31 (obtaining a vehicle operator license); and 460.7 (maintaining records of crew training).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. “Statements” in Proposed §§ 3.403(a), 3.405(a), 402.3(a), and 402.5(a)</HD>
                <P>
                    Proposed §§ 3.403(a), 3.405(a), 402.3(a), and 402.5(a) apply to “statements.” Over the years, the falsification regulations have proscribed false statements and entries.
                    <SU>43</SU>
                    <FTREF/>
                     Regardless of whether one characterizes a particular representation as a “statement” or “entry,” when it is intentionally false or fraudulent, it is subject to the falsification proscription. The elimination of the word “entry” is intended to simplify the proposed rulemaking and is not intended to make a substantive change. The term “statement” references any information a person provides in a document. Accordingly, proposed §§ 3.403(a) and 402.3(a) would provide that “[n]o person may make or cause to be made any fraudulent or intentionally false statement” in any of the documents described in proposed §§ 3.403(a)(1)-(2) and 402.3(a)(1)-(2). Sections 3.405(a) and 402.5(a) would provide that “[n]o person may make or cause to be made a material incorrect statement” in any of the documents described in §§ 3.405(a)(1)-(2) and 402.5(a)(1)-(2).
                </P>
                <FTNT>
                    <P>
                        <SU>43</SU>
                         
                        <E T="03">See</E>
                         note 1, 
                        <E T="03">supra.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD2">D. Categories of “Any Document in Any Format” in Proposed §§ 3.403 and 3.405—14 CFR Chapter I</HD>
                <P>
                    The proposed rulemaking in relation to 14 CFR chapter I applies to “any document in any format.” Documents “in any format” include hard copy or other tangible format (like a data plate, stamped marks on parts, and bar codes) 
                    <PRTPAGE P="8569"/>
                    or electronic. The proposed rulemaking in relation to 14 CFR chapter I applies to two categories of documents. Proposed §§ 3.403(a)(1), 3.403(b)(1), 3.403(c)(1), and 3.405(a)(1) would consist of “[a]ny document in any format submitted under any provision referenced in § 3.401 of [proposed subpart D of part 3], consisting of or related to any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, record, report, request for reconsideration, or similar.” (“Category 1”). Table 2 contains examples of documents in Category 1.
                </P>
                <GPOTABLE COLS="2" OPTS="L2,nj,i1" CDEF="s50,r200">
                    <TTITLE>Table 2—Examples of Category 1 Documents—14 CFR Chapter I</TTITLE>
                    <BOXHD>
                        <CHED H="1">14 CFR chapter I—documents—proposed §§ 3.403(a)(1), 3.403(b)(1), 3.403(c)(1), and 3.405(a)(1)</CHED>
                        <CHED H="2">Category 1</CHED>
                        <CHED H="2">Examples</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Acceptance</ENT>
                        <ENT>Acceptance of aircraft engines and propellers (§ 21.500); Acceptance of Articles (§ 21.502).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Application</ENT>
                        <ENT>
                            <E T="03">See generally,</E>
                             parts 61 (
                            <E T="03">e.g.,</E>
                             application for pilot certificate), 67 (
                            <E T="03">e.g.,</E>
                             application for a medical certificate), 119 (
                            <E T="03">e.g.,</E>
                             application for an Air Carrier Certificate or Operating Certificate).
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Approval</ENT>
                        <ENT>Parts Manufacturer Approval (PMA) (Part 21, subpart K); Fatigue risk management system (§ 117.7); 121.141 Airplane Flight Manual (§ 121.141), Approval procedures of training courses (§ 141.13); SMS Implementation Plan, § 5.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Authorization</ENT>
                        <ENT>
                            Authorization for Special Issuance of a Medical Certificate (§ 67.401); Letter of Authorization (
                            <E T="03">e.g.,</E>
                             part 91); Inspector Authorization (§ 65.95).
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Certificate</ENT>
                        <ENT>
                            <E T="03">See generally,</E>
                             parts 61 
                            <E T="03">(e.g.,</E>
                             private, commercial airline transport pilot certificates), 63 (
                            <E T="03">e.g.,</E>
                             flight engineer certificate), 67 (
                            <E T="03">e.g.,</E>
                             medical certificate),145 (
                            <E T="03">e.g.,</E>
                             repair station certificate).
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Rating</ENT>
                        <ENT>Instrument rating (§ 61.65).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Declaration</ENT>
                        <ENT>Declaration of compliance (§ 89.535).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Designation</ENT>
                        <ENT>Kinds of Designations (part 183, subpart C).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Qualification</ENT>
                        <ENT>Flight Simulator Training Device qualification (§ 60.4).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Record</ENT>
                        <ENT>
                            Maintenance records (
                            <E T="03">e.g.,</E>
                             part 43); Pilot School Training Records (§ 141.101); Voting Trust Agreement and Affidavit (§ 47.8).
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Report</ENT>
                        <ENT>Safety analysis (§ 33.75); Comprehensive Medical Examination Checklist (§ 68.7).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Request for reconsideration</ENT>
                        <ENT>Request for reconsideration (§§ 67.407(c) and 67.409(a)).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Or similar</ENT>
                        <ENT>
                            Operations specifications (part 119); Product and Process specifications; Program Registrations (part 120); Waivers (
                            <E T="03">e.g.,</E>
                             part 107); Exemptions (
                            <E T="03">e.g.,</E>
                             part 139); Special Flight Permits (§ 21.197); Graduation Certificate (§ 141.95).
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <P>Proposed §§ 3.403(a)(2), 3.403(b)(2), 3.403(c)(2), and 3.405(a)(2) would consist of, “[a]ny document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 3.401 of this subpart” (“Category 2”).</P>
                <HD SOURCE="HD3">1. Scope of Category 1 in Proposed §§ 3.403(a)(1), 3.403(b)(1), 3.403(c)(1), and 3.405(a)(1)</HD>
                <P>The Category 1 documents in proposed §§ 3.403(a)(1), 3.403(b)(1), 3.403(c)(1), and 3.405(a)(1) may consist of an application, declaration, record, report, request for reconsideration, or similar, that a person submits to the FAA or a designee. The Category 1 documents that a person submits to the FAA or a designee may also be related to an acceptance, approval, authorization, certificate, rating, designation, qualification, or similar. For example, the FAA may request an airman seeking a medical certificate under part 67 to submit additional medical records related to qualification requirements under § 67.413. The “related to” language in the proposed rule would cover falsifications of the additional medical records. In either case, the intent of the proposed rule is to ensure that information the FAA is authorized to receive under statute and regulation in connection with the listed items is covered.</P>
                <HD SOURCE="HD3">2. Scope of Category 2 in Proposed Sections 3.403(a)(2), 3.403(b)(2), 3.403(c)(2), and 3.405(a)(2)</HD>
                <P>
                    The Category 2 documents in proposed §§ 3.403(a)(2), 3.403(b)(2), 3.403(c)(2), and 3.405(a)(2) are consistent with the familiar prescription, “made, kept, or used, to show compliance with any requirement,” that is nearly ubiquitous in the falsification regulations.
                    <SU>44</SU>
                    <FTREF/>
                     Category 2 documents may include, for example, pilot logbook records and aircraft maintenance records. Such records are kept, made, or used to show compliance with applicable regulatory requirements. In contrast to Category 1 documents, Category 2 documents are not necessarily submitted to the FAA. Proposed §§ 3.403(a)(2), 3.403(b)(2), 3.403(c)(2), and 3.405(a)(2) would not include the words “developed” or “provided,” which is terminology used in 14 CFR 89.5(a)(2) and (b)(2). These terms are redundant of the terms “made, kept, or used” in the proposed rulemaking. Their removal is not intended to narrow the scope of documents subject to the proposed rulemaking.
                </P>
                <FTNT>
                    <P>
                        <SU>44</SU>
                         
                        <E T="03">See</E>
                         14 CFR 21.2(a)(2), 43.12(a)(1), 60.33(a)(2), 61.59(a)(2), 63.20(a)(2), 65.20(a)(2), 67.403(a)(2); 107.5(a)(1); 139.115(a)(2), 145.12(a)(1)(i); 
                        <E T="03">see also,</E>
                         14 CFR 89.5(a)(2)(“developed, provided, kept, or used”); 111.35(c), 120.103(e)(2), 120.213(b) (“kept, made, or used), and 121.9(a)(2) (“kept, made, or used”).
                    </P>
                </FTNT>
                <P>
                    Consistent with many existing falsification regulations, Category 2 would not condition the applicability of the falsification prohibition on a requirement that the “document in any format” be kept, made, or used to show compliance. This approach reflects the FAA's position in the 2014 amendments to part 145. In that rule, the FAA eliminated the phrase “required to be” with regard to any record or report made, kept, or used to show compliance. The FAA did so “to forestall an argument a falsifier could make that, although the falsification occurred in a record or report that was made, kept, or used to show compliance, it was not a record or report that was required by a regulation to be made or kept.” 
                    <SU>45</SU>
                    <FTREF/>
                     The NTSB had already rejected that argument in addressing a violation of 14 CFR 43.12,
                    <SU>46</SU>
                    <FTREF/>
                     noting that 
                    <PRTPAGE P="8570"/>
                    the phrase should not be restricted to mean “required” by the FAA Administrator because the term can also be broadly construed to mean required by the circumstances for which compliance is sought or necessary.
                    <SU>47</SU>
                    <FTREF/>
                     The elimination of the phrase “required to be” is consistent with the falsification regulations that do not contain that phrase.
                    <SU>48</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>45</SU>
                         79 FR 46980 (Aug. 12, 2014).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>46</SU>
                         
                        <E T="03">Adm'r</E>
                         v. 
                        <E T="03">Anderson,</E>
                         NTSB No. EA-4564, 1997 WL 355350 at *2 (June 26, 1997) (agreeing with the FAA's “clearly reasonable position that the regulation reaches falsifications in any maintenance documents actually kept or used to show compliance with a requirement in part 43, whether or not they are records in a form or format the 
                        <PRTPAGE/>
                        Administrator specifically requires an individual to use or keep for that purpose”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>47</SU>
                         
                        <E T="03">Anderson,</E>
                         NTSB No. EA-4564 at *3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>48</SU>
                         
                        <E T="03">See</E>
                         14 CFR 21.2(a)(2), 60.33(a)(2), 67.403(a)(2), 111.35(c), 120.103(e)(2), 120.213(b), 121.9(a)(2), 145.12(a)(1)(i) and (b)(2).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">E. Categories of “Any Document In Any Format” in Proposed §§ 402.3 and 402.5—14 CFR Chapter III</HD>
                <P>The proposed rulemaking in relation to 14 CFR chapter III, applies to two categories of “any document in any format,” as that terminology is defined in Section C. Proposed §§ 402.3(a)(1), 402.3(b)(1), 402.3(c)(1), and 402.5(a)(1) would consist of “[a]ny document in any format submitted under any provision referenced in § 402.1 of [part 402], consisting of or related to any acceptance, application, approval, authorization, permit, license, waiver, record, report, or similar,” (“Category 1”). Table 4 contains examples of documents in Category 1.</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,i1" CDEF="s50,r200">
                    <TTITLE>Table 3—Examples of Category 1 Documents—14 CFR Chapter III</TTITLE>
                    <BOXHD>
                        <CHED H="1">14 CFR Chapter I—Documents—Proposed §§ 402.3(a)(1), 402.3(b)(1), 402.3(c)(1), and 402.5(a)(1)</CHED>
                        <CHED H="2">Category 1</CHED>
                        <CHED H="2">Examples</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Acceptance</ENT>
                        <ENT>Acceptance of an application (§ 413.11); Acceptance of a means of compliance (§ 450.35).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Application</ENT>
                        <ENT>Application submission (§ 413.7).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Approval</ENT>
                        <ENT>Safety Element Approval (part 414); Policy Approval (§ 450.41).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Authorization</ENT>
                        <ENT>Certificate of Waiver or Authorization (§ 437.71(d)(2)); Authorization to conduct reusable launch vehicle missions (§ 431.3(a)).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Permit</ENT>
                        <ENT>Experimental Permit (part 437).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">License</ENT>
                        <ENT>License Application Procedures (part 413); Launch License (part 415); Launch and Reentry of a Reusable Launch Vehicle (part 431); License to Operate a Reentry Site (part 433); Reentry of a Reentry Vehicle Other Than A Reusable Launch Vehicle (part 435); License to Operate a Launch Site (part 420); Launch and Reentry License Requirements (part 450).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Waiver</ENT>
                        <ENT>Filing a petition for waiver (14 CFR 404.5).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Record</ENT>
                        <ENT>Records under 14 CFR §§ 417.15, 431.77, 437.87, and 450.219.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Report</ENT>
                        <ENT>Reusable launch vehicle mission reporting requirements (§ 431.79); Anomaly reporting (§ 437.73); Mishap plan-reporting, response, and investigation requirements (§ 450.173); Pre-flight reporting (§ 450.213); Post-flight reporting (§ 450.215).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Or similar</ENT>
                        <ENT>Demonstration of Financial Responsibility and Compliance with Allocation of Risk Requirements Under part 440; Payload Determination (part 415); Demonstration of Compliance (§ 440.15).</ENT>
                    </ROW>
                </GPOTABLE>
                <P>Proposed §§ 402.3(a)(2), 402.3(b)(2), 402.3(c)(2), and 402.5(a)(2) would consist of, “[a]ny document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 402.1 of [part 402]” (“Category 2”).</P>
                <HD SOURCE="HD3">1. Scope of Category 1 in Proposed Sections 402.3(a)(1), 402.3(b)(1), 402.3(c)(1), and 402.5(a)(1)</HD>
                <P>
                    Category 1 documents in proposed §§ 402.3(a)(1), 402.3(b)(1), 402.3(c)(1), and 402.5(a)(1) consist of the listed items (
                    <E T="03">i.e.,</E>
                     “acceptance, application . . .”) or documents that are related to them. Listed items in these sections are specific to 14 CFR chapter III, subchapter C, and necessarily vary from the listed items in the proposed rulemaking as it applies to 14 CFR chapter I since these items are in the context of commercial space.
                </P>
                <HD SOURCE="HD3">2. Scope of Category 2 in Proposed §§ 402.3(a)(2), 402.3(b)(2), 402.3(c)(2), and 402.5(a)(2)</HD>
                <P>Category 2 documents in proposed §§ 402.3(a)(2), 402.3(b)(2), 402.3(c)(2), and 402.5(a)(2) are modeled upon, and consistent with, the terminology in Category 2 in the proposed rule as it applies to 14 CFR chapter I, albeit applicable to commercial space.</P>
                <HD SOURCE="HD2">F. Fraudulent or Intentionally False Statements or Entries in Proposed §§ 3.403(a) and 402.3(a)</HD>
                <P>Proposed §§ 3.403(a) and 402.3(a) would prohibit fraudulent or intentionally false statements in the Category 1 and 2 documents described in Sections D and E of the “Discussion of the Proposal” section of this NPRM. Both fraud and intentional falsification have clear and long-standing definitions established in precedent. The elements of fraud and intentional falsification are defined in Section I. B. “Background” of this NPRM. The FAA would not deviate from these established definitions of fraud and intentional falsification in the proposed rule.</P>
                <HD SOURCE="HD2">G. Production, Reproduction, Alteration, for Fraudulent Purpose in Proposed §§ 3.403(b) and 402.3(b)</HD>
                <P>
                    Proposed §§ 3.403(b) and 402.3(b) prohibit any production, reproduction, or alteration for a fraudulent purpose of the Category 1 and 2 documents described in Sections D and E of the “Discussion of the Proposal” section of this NPRM. Reproductions for a fraudulent purpose and alterations, including alterations for a fraudulent purpose, are proscribed in various falsification regulations.
                    <SU>49</SU>
                    <FTREF/>
                     While some of these regulations prohibit any alteration of the applicable document 
                    <E T="03">(i.e.,</E>
                     14 CFR 21.2(a)(4), 61.59(a)(4), 65.20(a)(4), and 67.403(a)(4)), others prohibit only fraudulent alterations of the applicable document (
                    <E T="03">i.e.,</E>
                     14 CFR 43.12(a)(3), 60.33(a)(3), 107.5(a)(2), and 145.12(a)(3)).
                </P>
                <FTNT>
                    <P>
                        <SU>49</SU>
                         Such prohibitions are found at 14 CFR 21.2(a)(3)-(4), 43.12(a)(2)-(3), 60.33(a)(3), 61.59(a)(3)-(4), 63.20(a)(3)-(4), 65.20(a)(3)-(4), 67.403(a)(3)-(4), 89.5(a)(3), 107.5(a)(2), 120.103(e)(3), 121.9(a)(2), 139.115(a)(3)-(4), and 145.12(a)(2)-(3). A “fraudulent purpose” consists of the three elements of an intentional false statement plus an intent to deceive. 
                        <E T="03">See Adm'r</E>
                         v. 
                        <E T="03">Coomber,</E>
                         NTSB Order No. EA-4283 (1994). It does not require action taken in reliance. 
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <P>
                    Proposed §§ 3.403(b) and 402.3(b) would standardize this prohibition to those reproductions and alterations that are for a fraudulent purpose. These proposed sections would also prohibit a “production” for a fraudulent purpose 
                    <PRTPAGE P="8571"/>
                    of the Category 1 or 2 documents. This provision is meant to capture those instances where an individual or entity creates a document, such as a certificate or authorization, rather than altering an authentic existing document. In that case, the false document would be neither a reproduction nor an alteration. In the context of 14 CFR chapter I, this provision would apply, for example, to persons that create a certificate (
                    <E T="03">e.g.,</E>
                     an airman certificate or an airworthiness certificate) for a fraudulent purpose.
                </P>
                <HD SOURCE="HD2">H. Knowingly Omitting or Causing To Be Omitted a Material Fact Under Proposed §§ 3.403(c) and 402.3(c)</HD>
                <P>Proposed §§ 3.403(c) and 402.3(c) would prohibit a person from knowingly omitting, or causing to be omitted, a material fact in the Category 1 or 2 documents described in Sections D and E under the “Discussion of the Proposal” in this NPRM. These proposed sections would correct inconsistencies in the “omission” prohibitions in the falsification regulations.</P>
                <P>
                    The falsification regulations that address omissions do so inconsistently by prohibiting (1) “knowingly concealing or causing to be concealed, by omission, a material fact” (14 CFR 89.5(b)(1)-(2) and 145.12(b)(1)-(2)); (2) “concealing or causing to be concealed a material fact” (14 CFR 111.35(a)-(c)); and (3) “known omissions” (14 CFR 60.33(a)(2) and 121.9(a)(2)). The “concealment” terminology is unnecessary. When the FAA amended 14 CFR part 145 in 2014, it explained that a knowing concealment of a material fact is triggered when a person knew that they failed to include the material fact in the document at issue.
                    <SU>50</SU>
                    <FTREF/>
                     Whether a person knowingly conceals a material fact by an omission or knowingly omits a material fact, the result is the same: the person knew that they omitted a material fact.
                    <SU>51</SU>
                    <FTREF/>
                     The “known omission” prohibition in 14 CFR 60.33 and 121.9 lacks a materiality element. Regarding § 60.33, the FAA previously stated that it had “added the word `material' to the phrase `known omission' to clarify that only important, known omissions (
                    <E T="03">i.e.,</E>
                     from a statement or writing) would constitute a violation” on par with a fraudulent or intentionally false statement or entry.
                    <SU>52</SU>
                    <FTREF/>
                     A knowing omission of a material fact can have a detrimental impact on aviation and public safety to the same degree as an affirmative falsification. Accordingly, the FAA would incorporate this prohibition into the proposed rulemaking for 14 CFR chapter I and chapter III.
                </P>
                <FTNT>
                    <P>
                        <SU>50</SU>
                         
                        <E T="03">See</E>
                         79 FR 46971 (Aug. 12, 2014).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>51</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>52</SU>
                         
                        <E T="03">See</E>
                         71 FR 63422 (Oct. 30, 2006). Although the FAA stated that it was adding “material” to “known omissions,” it appears that this change was never incorporated into the regulatory text.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">I. Sanction Under Proposed §§ 3.403(d) and 402.3(d) for Conduct Described in Sections F, G, and H of This NPRM</HD>
                <P>
                    Proposed §§ 3.403(d) and 402.3(d) would contain the sanction provision respectively applicable to violations of proposed §§ 3.403(a)-(c) and 402.3(a)-(c). It would provide for two categories of sanction: (1) FAA actions (
                    <E T="03">i.e.,</E>
                     denial, suspension, modification, revocation, recension, removal, or withdrawal) involving any issuance or grant by the Administrator under 14 CFR chapter I or III; or (2) a civil penalty. Consistent with longstanding FAA sanction policy, the termination of an FAA issuance or grant of the type of item referenced in the proposed rule, such as a certificate revocation, remains the appropriate consequence for violating proposed §§ 3.403(a)-(c) and 402.3(a)-(c).
                    <SU>53</SU>
                    <FTREF/>
                     Such violations seriously impact the integrity of the records on which the FAA's safety oversight depends. If the reliability of these records is undermined, the FAA's ability to promote aviation and public safety is compromised.
                </P>
                <FTNT>
                    <P>
                        <SU>53</SU>
                         
                        <E T="03">See</E>
                         FAA Order 2150.3C, chap. 9, para. 8.
                    </P>
                </FTNT>
                <P>
                    Some of the current falsification regulations limit the scope of sanction to items issued under the part where the falsification regulation is located. For instance, § 21.2(a)(2) limits the suspension or revocation of any certificate or approval issued under part 21. Proposed §§ 3.403(d) and 402.3(d) would generally allow for the extension of those consequences to any issuance or grant by the FAA and held by the falsifier. This is consistent with FAA sanction guidance, which provides that violation of the falsification regulations is an offense that generally warrants the revocation of 
                    <E T="03">all</E>
                     certificates held by the certificate holder if allowed by the scope of the regulation.
                    <SU>54</SU>
                    <FTREF/>
                     This proposal ensures that such consequences are not limited to certificates and extend to any issuance or grant the falsifier holds.
                </P>
                <FTNT>
                    <P>
                        <SU>54</SU>
                         
                        <E T="03">See</E>
                         Order 2150.3C, chap. 9, para. 8.a.(2)(i)-(ii), which states: 
                    </P>
                    <P>(i) Not only is revocation appropriate for conduct demonstrating a lack of care, judgment, or responsibility, the scope of the certificates affected by the revocation generally includes all certificates held regardless of which certificate (if any) was used at the time of the conduct. </P>
                    <P>* * * * *</P>
                    <P>(ii) For certain violations demonstrating a lack of care, judgment, or responsibility, the scope of certificates affected is dictated by statute or regulation. For example, the scope of certificates affected by making a fraudulent or intentional false statement on an application for an airman medical certificate in violation of 14 CFR 67.403 is broad; this regulation provides a basis to revoke all airman (including medical) and ground instructor certificates. Further, an intentional falsification on an application for a certificate issued under 14 CFR part 61 is a basis for revoking any airman certificate, rating, or authorization.</P>
                </FTNT>
                <P>Under proposed §§ 3.403(d)(2) and 402.3(d)(2), the proscribed conduct may in certain circumstances warrant imposition of a civil penalty against an individual or entity, either in addition to or in combination with an action against a certificate, license, or other issuance or grant. For example, a civil penalty may be appropriate for uncertificated persons that commit a falsification. The appropriate sanction or combination of sanctions is within the prosecutorial discretion of the FAA in accordance with agency sanction guidance policy in publicly available FAA Order 2150.3C, as amended.</P>
                <HD SOURCE="HD2">J. Incorrect Statements, or Omissions Under Proposed §§ 3.405 and 402.5</HD>
                <P>
                    Proposed §§ 3.405(a)(1)-(2) and 402.5(a)(1)-(2) would prohibit persons from making or causing to be made a material incorrect statement or omitting or causing to be omitted a material fact, in the Category 1 or 2 documents described in Sections D and E under the “Discussion of the Proposal” in this NPRM. Currently, incorrect statements or entries upon which the FAA relied may serve as a basis for an FAA action under 14 CFR 60.33(c)(1)-(2) (
                    <E T="03">e.g.,</E>
                     removal of a qualification) and 67.403(c)(1)-(2) (
                    <E T="03">e.g.,</E>
                     revocation of a medical certificate). Proposed §§ 3.405(a)(1)-(2) and 402.5(a)(1)-(2) would prohibit material incorrect statements or entries without prescribing reliance by the FAA. Material incorrect statements or entries, 
                    <E T="03">i.e.,</E>
                     incorrect statements or entries that are capable of influencing an agency decision, may have an adverse impact on safety under 14 CFR chapters I and III. Proposed §§ 3.405(a)(1)-(2) and 402.5(a)(1)-(2) would provide a basis for appropriate action, as explained in Section K. below, when a person unknowingly provides material incorrect information, whether or not the FAA relied upon it.
                </P>
                <P>
                    Proposed §§ 3.405(a)(1)-(2) and 402.5(a)(1)-(2) would also prohibit omissions of material facts from the Category 1 or 2 documents described in Sections D and E under the “Discussion of the Proposal” in this NPRM. Those proposed sections would apply to unknowing omissions of material fact, in contrast to the proscription of knowing omissions of material fact in proposed §§ 3.403(c)(1)-(2) and 
                    <PRTPAGE P="8572"/>
                    402.3(c)(1)-(2). An unknowing omission of a material fact can have a detrimental impact on aviation and public safety to the same degree as a knowing omission of material fact. Accordingly, the FAA would incorporate this prohibition into the proposed rulemaking for 14 CFR chapter I and chapter III.
                </P>
                <P>
                    Proposed § 3.405(a)(1)-(2) would ensure coverage of the scope of prohibited conduct in 14 CFR 142.11(e)(3) that deviated from prior falsification regulations (
                    <E T="03">i.e.,</E>
                     “incomplete,” “inaccurate,” or “false information” (and not “intentionally false information”)).” 
                    <SU>55</SU>
                    <FTREF/>
                     Proposed § 3.405(a)(1)-(2) would cover (1) “incomplete” information submitted under 14 CFR 142.11(e)(3) as an omission of a material fact (so long as the person unknowingly omitted it), and (2) “inaccurate” and unintentionally “false” information submitted under 14 CFR 142.11(e)(3) as a material incorrect statement or entry.
                    <SU>56</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>55</SU>
                         14 CFR 142.11(e)(3).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>56</SU>
                         Proposed § 3.403(a)-(c) would cover “fraudulent” or (intentionally) “false” information submitted under 14 CFR 142.11(e)(3).
                    </P>
                </FTNT>
                <P>
                    Proposed § 3.405(a)(1)-(2) would create consistency by expanding the prohibition to the parts of 14 CFR chapter I that contain falsification regulations but do not currently prohibit such conduct, and to the applicable parts of 14 CFR chapter I generally, which are referenced in proposed § 3.401.
                    <SU>57</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>57</SU>
                         The falsification regulations that prohibit incorrect statements or entries are 14 CFR 60.33(c) and 67.403(c). Those that do not are 14 CFR 21.2, 43.12, 61.59, 63.20, 65.20, 120.103(e), 120.213, 121.9, 139.115, 142.11(e)(3), and 145.12.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">K. Sanction Under Proposed §§ 3.405(b) and 402.5(b) for Incorrect Statements, or Omissions</HD>
                <P>Proposed §§ 3.405(b) and 402.5(b) would permit the agency to deny, suspend, modify, revoke, rescind, remove, or withdraw any issuance or grant by the Administrator under 14 CFR chapter I or III for conduct described in Section J of the “Discussion of the Proposal” in this NPRM. The intent behind proposed §§ 3.405(b) and 402.5(b) would not be punitive, but rather remedial and preventive in an effort to cure unintended defects in documents under proposed §§ 3.403, 3.405, 402.3, and 402.5. A material incorrect statement or entry, or omission of a material fact, generally warrants an action against the issuance or grant in response to the document(s) containing an incorrect statement, entry, or omission. For example, generally, the appropriate sanction for an incorrect statement on an application for an airman medical certificate is revocation of that certificate. The individual impacted would then be able to submit a new corrected application. Proposed §§ 3.405(b) and 402.5(b) do not require the FAA to take action against a person for an incorrect statement, entry, or omission of material fact. The FAA would use its prosecutorial discretion to determine whether such action was appropriate based on the totality of the circumstances of a particular case.</P>
                <HD SOURCE="HD1">IV. Regulatory Notices and Analyses</HD>
                <P>Federal agencies consider impacts of regulatory actions under a variety of executive orders and other requirements. First, Executive Order 12866 and Executive Order 13563, as amended by Executive Order 14094 (“Modernizing Regulatory Review”), direct that each Federal agency shall propose or adopt a regulation only upon a reasoned determination that the benefits of the intended regulation justify the costs. Second, the Regulatory Flexibility Act of 1980 (Pub. L. 96-354) requires agencies to analyze the economic impact of regulatory changes on small entities. Third, the Trade Agreements Act (Pub. L. 96-39) prohibits agencies from setting standards that create unnecessary obstacles to the foreign commerce of the United States. Fourth, the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4) requires agencies to prepare a written assessment of the costs, benefits, and other effects of proposed or final rules that include a Federal mandate that may result in the expenditure by State, local, and tribal governments, in the aggregate, or by the private sector, of $100 million or more (adjusted annually for inflation) in any one year. The current threshold after adjustment for inflation is $177 million using the most current (2022) Implicit Price Deflator for the Gross Domestic Product. This portion of the preamble summarizes the FAA's analysis of the economic impacts of this rule.</P>
                <P>In conducting these analyses, the FAA has determined that this proposed rule: is not a “significant regulatory action” as defined in section 3(f) of Executive Order 12866; will not have a significant economic impact on a substantial number of small entities; will not create unnecessary obstacles to the foreign commerce of the United States; and will not impose an unfunded mandate on State, local, or tribal governments, or on the private sector.</P>
                <HD SOURCE="HD3">Regulatory Evaluation</HD>
                <HD SOURCE="HD3">1. Need for the Regulation</HD>
                <P>Falsification regulations promote aviation and commercial space safety by incentivizing the provision of accurate and truthful information to the FAA. Through the proposed rule, the FAA intends to enhance aviation safety by standardizing the scope of conduct proscribed by falsification regulations that the FAA intends to deter across the applicable sections of 14 CFR parts 1 through 199 and 14 CFR parts 413 through 460 and extending this scope of conduct to the requirements of 14 CFR parts 1 through 199 and 14 CFR parts 413 through 460 that currently do not have—but should have—falsification provisions. The proposed rule would also standardize sanction provisions for this conduct and allow for more consistent sanction determinations as appropriate.</P>
                <HD SOURCE="HD3">2. Benefits</HD>
                <P>The proposed rulemaking would benefit the safety of the public by ensuring that information made, kept, or used to show compliance with regulatory requirements or provided to the FAA is accurate and complete. The proposed rulemaking also benefits private industry by standardizing sanction provisions and providing consistent sanction determinations. Additional benefits to private industry include a more reliable aviation system that contains less risk and requires less mitigation and corrective action to address situations where a person has falsified a document.</P>
                <HD SOURCE="HD3">3. Costs</HD>
                <P>The FAA has evaluated the cost impacts to the stakeholders involved in this proposed rulemaking and does not anticipate any new cost impact to industry and the FAA as a result of this proposed rule.</P>
                <HD SOURCE="HD3">4. Regulatory Alternatives</HD>
                <P>The FAA considered no action as an alternative to this proposed rulemaking. However, taking no action would not achieve the needed harmonization and consolidation of the falsification regulations and standardization of the scope of conduct proscribed by falsification regulations.</P>
                <P>
                    The FAA has, therefore, determined that this proposed rule would have no new costs but positive benefits and does not warrant a full regulatory evaluation. The FAA has also determined that this proposed rule is not a “significant regulatory action” as defined in section 3(f) of Executive Order 12866 and is not 
                    <PRTPAGE P="8573"/>
                    “significant” as defined in DOT's Regulatory Policies and Procedures.
                </P>
                <HD SOURCE="HD2">B. Regulatory Flexibility Act</HD>
                <P>The Regulatory Flexibility Act of 1980, Public Law 96-354, 94 Stat. 1164 (5 U.S.C. 601-612), as amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121, 110 Stat. 857, Mar. 29, 1996) and the Small Business Jobs Act of 2010 (Pub. L. 111-240, 124 Stat. 2504 Sept. 27, 2010), requires Federal agencies to consider the effects of the regulatory action on small businesses and other small entities and to minimize any significant economic impact. The term “small entities” comprises small businesses and not-for-profit organizations that are independently owned and operated and are not dominant in their fields and governmental jurisdictions with populations of less than 50,000.</P>
                <P>The FAA has not identified any small entities that would be affected by the proposed rule because this proposed standardization of the scope of conduct proscribed by falsification regulations does not add any new costs to regulated entities. Therefore, the FAA certifies that the proposed rule will not have a significant economic impact on small entities. The FAA welcomes comments on the basis for this certification.</P>
                <HD SOURCE="HD2">C. International Trade Impact Assessment</HD>
                <P>The Trade Agreements Act of 1979 (Pub. L. 96-39), as amended by the Uruguay Round Agreements Act (Pub. L. 103-465), prohibits Federal agencies from establishing standards or engaging in related activities that create unnecessary obstacles to the foreign commerce of the United States. Pursuant to these Acts, the establishment of standards is not considered an unnecessary obstacle to the foreign commerce of the United States, so long as the standard has a legitimate domestic objective, such as the protection of safety, and does not operate in a manner that excludes imports that meet this objective. The statute also requires consideration of international standards and, where appropriate, that they be the basis for U.S. standards. The FAA has determined that this proposed rule is not considered an unnecessary obstacle to trade.</P>
                <P>The FAA has assessed the potential effect of this proposed rule and determined that it ensures the safety of the American public and does not exclude imports that meet this objective. As a result, the FAA does not consider this proposed rule as creating an unnecessary obstacle to foreign commerce.</P>
                <HD SOURCE="HD2">D. Unfunded Mandates Assessment</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) governs the issuance of Federal regulations that require unfunded mandates. An unfunded mandate is a regulation that requires a State, local, or tribal government or the private sector to incur direct costs without the Federal government having first provided the funds to pay those costs. The FAA determined that the proposed rule will not result in the expenditure of $177 million or more by State, local, or tribal governments, in the aggregate, or the private sector, in any one year.</P>
                <P>This proposed rule does not contain such a mandate; therefore, the requirements of title II of the Act do not apply.</P>
                <HD SOURCE="HD2">E. Paperwork Reduction Act</HD>
                <P>The Paperwork Reduction Act of 1995 (44 U.S.C. 3507(d)) requires that the FAA consider the impact of paperwork and other information collection burdens imposed on the public. The FAA has determined that there would be no new requirement for information collection associated with this proposed rule.</P>
                <HD SOURCE="HD2">F. International Compatibility</HD>
                <P>In keeping with U.S. obligations under the Convention on International Civil Aviation, it is FAA policy to conform to International Civil Aviation Organization (ICAO) Standards and Recommended Practices to the maximum extent practicable. The FAA has determined that there are no ICAO Standards and Recommended Practices that correspond to these proposed regulations.</P>
                <HD SOURCE="HD2">G. Environmental Analysis</HD>
                <P>FAA Order 1050.1F identifies FAA actions that are categorically excluded from preparation of an environmental assessment or environmental impact statement under the National Environmental Policy Act in the absence of extraordinary circumstances. The FAA has determined this rulemaking action qualifies for the categorical exclusion identified in paragraph 5-6.6(f) for regulations and involves no extraordinary circumstances.</P>
                <HD SOURCE="HD1">V. Executive Order Determinations</HD>
                <HD SOURCE="HD2">A. Executive Order 13132, Federalism</HD>
                <P>The FAA has analyzed this proposed rule under the principles and criteria of Executive Order (E.O.) 13132, Federalism. The FAA has determined that this action would not have a substantial direct effect on the States, or the relationship between the Federal Government and the States, or on the distribution of power and responsibilities among the various levels of government, and, therefore, would not have federalism implications.</P>
                <HD SOURCE="HD2">B. Executive Order 13175, Consultation and Coordination With Indian Tribal Governments</HD>
                <P>Consistent with Executive Order 13175, Consultation and Coordination with Indian Tribal Governments, and FAA Order 1210.20, American Indian and Alaska Native Tribal Consultation Policy and Procedures, the FAA ensures that Federally Recognized Tribes (Tribes) are given the opportunity to provide meaningful and timely input regarding proposed Federal actions that have the potential to affect uniquely or significantly their respective Tribes. At this point, the FAA has not identified any unique or significant effects, environmental or otherwise, on tribes resulting from this proposed rule.</P>
                <HD SOURCE="HD2">C. Executive Order 13211, Regulations That Significantly Affect Energy Supply, Distribution, or Use</HD>
                <P>The FAA analyzed this proposed rule under Executive Order 13211, Actions Concerning Regulations that Significantly Affect Energy Supply, Distribution, or Use (May 18, 2001). The FAA has determined that it would not be a “significant energy action” under the executive order and would not be likely to have a significant adverse effect on the supply, distribution, or use of energy.</P>
                <HD SOURCE="HD2">D. Executive Order 13609, Promoting International Regulatory Cooperation</HD>
                <P>Executive Order 13609, Promoting International Regulatory Cooperation, promotes international regulatory cooperation to meet shared challenges involving health, safety, labor, security, environmental, and other issues and to reduce, eliminate, or prevent unnecessary differences in regulatory requirements. The FAA has analyzed this proposed action under the policies and agency responsibilities of E.O. 13609 and has determined that this proposed action would have no effect on international regulatory cooperation.</P>
                <HD SOURCE="HD1">VI. Additional Information</HD>
                <HD SOURCE="HD2">A. Comments Invited</HD>
                <P>
                    The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. The FAA also invites comments relating to the economic, environmental, energy, or federalism impacts that might 
                    <PRTPAGE P="8574"/>
                    result from adopting the proposals in this document. 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.
                </P>
                <P>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.</P>
                <P>
                    <E T="03">Proprietary or Confidential Business Information:</E>
                     Do not file proprietary or confidential business information in the docket. Such information must be sent or delivered directly to the person identified in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this document and marked as proprietary or confidential. If submitting information on a disk or CD ROM, mark the outside of the disk or CD ROM, and identify electronically within the disk or CD ROM the specific information that is proprietary or confidential.
                </P>
                <P>Under § 11.35(b), if the FAA is aware of proprietary information filed with a comment, the agency does not place it in the docket. It is held in a separate file to which the public does not have access, and the FAA places a note in the docket that it has received it. If the FAA receives a request to examine or copy this information, it treats it as any other request under the Freedom of Information Act (5 U.S.C. 552). The FAA processes such a request under Department of Transportation procedures found in 49 CFR part 7.</P>
                <HD SOURCE="HD2">B. Availability of Rulemaking Documents</HD>
                <P>An electronic copy of a rulemaking document may be obtained by using the internet—</P>
                <P>
                    1. Search the Federal eRulemaking Portal (
                    <E T="03">www.regulations.gov</E>
                    );
                </P>
                <P>
                    2. Visit the FAA's Regulations and Policies web page at 
                    <E T="03">www.faa.gov/regulations_policies/</E>
                    ; or
                </P>
                <P>
                    3. Access the Government Printing Office's web page at 
                    <E T="03">www.GovInfo.gov.</E>
                </P>
                <P>Copies may also be obtained by sending a request (identified by notice or docket number of this rulemaking) to the Federal Aviation Administration, Office of Rulemaking, ARM-1, 800 Independence Avenue SW, Washington, DC 20591, or by calling (202) 267-9680.</P>
                <P>All documents the FAA considered in developing this proposed rule, including economic analyses and technical reports, may be accessed from the internet through the Federal eRulemaking Portal referenced in item (1) above.</P>
                <HD SOURCE="HD2">C. Small Business Regulatory Enforcement Fairness Act</HD>
                <P>
                    The Small Business Regulatory Enforcement Fairness Act (SBREFA) of 1996 requires the FAA to comply with small entity requests for information or advice about compliance with statutes and regulations within its jurisdiction. A small entity with questions regarding this document may contact its local FAA official or the person listed under the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     heading at the beginning of the preamble. To find out more about SBREFA on the internet, visit 
                    <E T="03">www.faa.gov/regulations_policies/rulemaking/sbre_act/.</E>
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects</HD>
                    <CFR>14 CFR Part 3</CFR>
                    <P>Aircraft, Aviation safety, Fraud.</P>
                    <CFR>14 CFR Part 5</CFR>
                    <P>Administrative practice and procedure, Air carriers, Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 21</CFR>
                    <P>Aircraft, Aviation safety, Exports, Imports, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 43</CFR>
                    <P>Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 45</CFR>
                    <P>Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 47</CFR>
                    <P>Aircraft, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 48</CFR>
                    <P>Aircraft, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 60</CFR>
                    <P>Airmen, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 61</CFR>
                    <P>Airmen, Alcohol abuse, Aviation safety, Drug abuse, Recreation and recreation areas, Reporting and recordkeeping requirements, Security measures, Teachers.</P>
                    <CFR>14 CFR Part 63</CFR>
                    <P>Aircraft, Airman, Alcohol abuse, Aviation safety, Drug abuse, Navigation (air), Reporting and recordkeeping requirements, Security measures.</P>
                    <CFR>14 CFR Part 65</CFR>
                    <P>Air traffic controllers, Aircraft, Airmen, Airports, Alcohol abuse, Aviation safety, Drug abuse, Reporting and recordkeeping requirements, Security measures.</P>
                    <CFR>14 CFR Part 67</CFR>
                    <P>Airmen, Authority delegations (Government agencies), Health, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 68</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Health, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 77</CFR>
                    <P>Air traffic control, Aircraft, Aviation safety, Navigation (air).</P>
                    <CFR>14 CFR Part 89</CFR>
                    <P>Air traffic control, Aircraft, Airmen, Aviation safety, Reporting and recordkeeping requirements, Security measures, Unmanned aircraft.</P>
                    <CFR>14 CFR Part 91</CFR>
                    <P>Afghanistan, Agriculture, Air carriers, Air taxis, Air traffic control, Aircraft, Airmen, Airports, Alaska, Aviation safety, Canada, Charter flights, Cuba, Drug traffic control, Ethiopia, Freight, Iraq, Libya, Mexico, Noise control, North Korea, Political candidates, Reporting and recordkeeping requirements, Security measures, Somalia, Syria, Transportation, Yugoslavia.</P>
                    <CFR>14 CFR Part 93</CFR>
                    <P>Air traffic control, Aircraft, Aviation safety, Navigation (air).</P>
                    <CFR>14 CFR Part 99</CFR>
                    <P>Air traffic control, Aircraft, Aviation safety, Security measures.</P>
                    <CFR>14 CFR Part 101</CFR>
                    <P>Aircraft, Aviation safety, Balloons, Rockets.</P>
                    <CFR>14 CFR Part 103</CFR>
                    <P>Aircraft, Airmen, Aviation safety.</P>
                    <CFR>14 CFR Part 105</CFR>
                    <P>
                        Aircraft, Aviation safety, Parachutes, Recreation and recreation areas, 
                        <PRTPAGE P="8575"/>
                        Reporting and recordkeeping requirements.
                    </P>
                    <CFR>14 CFR Part 107</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Reporting and recordkeeping requirements, Security measures.</P>
                    <CFR>14 CFR Part 111</CFR>
                    <P>Administrative practice and procedure, Air carriers, Air operators, Air taxis, Aircraft, Airmen, Alcohol abuse, Aviation safety, Charter flights, Drug abuse, Public aircraft, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 117</CFR>
                    <P>Airmen, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 119</CFR>
                    <P>Administrative practice and procedure, Air carriers, Aircraft, Airmen, Aviation safety, Charter flights, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 120</CFR>
                    <P>Air carriers, Air traffic controllers, Airmen, Alcohol abuse, Alcoholism, Aviation safety, Drug abuse, Drug testing, Reporting and recordkeeping requirements, Safety, Transportation.</P>
                    <CFR>14 CFR Part 121</CFR>
                    <P>Air carriers, Aircraft, Airmen, Alcohol abuse, Aviation safety, Charter flights, Drug abuse, Drug testing, Reporting and recordkeeping requirements, Safety, Transportation.</P>
                    <CFR>14 CFR Part 125</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 129</CFR>
                    <P>Air carriers, Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 133</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Helicopters.</P>
                    <CFR>14 CFR Part 135</CFR>
                    <P>Air taxis, Aircraft, Airmen, Alcohol abuse, Aviation Safety, Drug abuse, Drug testing, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 136</CFR>
                    <P>Air transportation, Aircraft, Aviation safety, National parks, Recreation and recreation areas, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 137</CFR>
                    <P>Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 139</CFR>
                    <P>Air carriers, Aircraft, Airports, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 141</CFR>
                    <P>Air transportation, Aircraft, Aircraft pilots, Airmen, Aviation safety, Education, Educational facilities, Helicopters, Reporting and recordkeeping requirements, Rotorcraft, Schools, Students, Teachers, Transportation.</P>
                    <CFR>14 CFR Part 142</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Educational facilities, Reporting and recordkeeping requirements, Schools, Students, Teachers.</P>
                    <CFR>14 CFR Part 145</CFR>
                    <P>Aircraft, Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 147</CFR>
                    <P>Aircraft, Airmen, Aviation safety, Education, Educational facilities, Reporting and recordkeeping requirements, Schools.</P>
                    <CFR>14 CFR Part 183</CFR>
                    <P>Aircraft, Airmen, Authority delegations (Government agencies), Aviation safety, Reporting and recordkeeping requirements.</P>
                    <CFR>14 CFR Part 402</CFR>
                    <P>Fraud, Reporting and recordkeeping requirements, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 413</CFR>
                    <P>Confidential business information, Reporting and recordkeeping requirements, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 414</CFR>
                    <P>Aviation safety, Confidential business information, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 415</CFR>
                    <P>Aviation safety, Environmental protection, Reporting and recordkeeping requirements, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 417</CFR>
                    <P>Aviation safety, Reporting and recordkeeping requirements, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 420</CFR>
                    <P>Airspace, Aviation safety, Environmental protection, Reporting and recordkeeping requirements, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 431</CFR>
                    <P>Aviation safety, Environmental protection, Investigations, Reporting and recordkeeping requirements, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 433</CFR>
                    <P>Aviation safety, Environmental protection, Investigations, Reporting and recordkeeping requirements, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 435</CFR>
                    <P>Aviation safety, Environmental protection, Investigations, Reporting and recordkeeping requirements, Rockets, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 437</CFR>
                    <P>Airspace, Aviation safety, Rockets, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 440</CFR>
                    <P>Indemnity payments, Insurance, Reporting and recordkeeping requirements, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 450</CFR>
                    <P>Aircraft, Aviation safety, Environmental protection, Investigations, Reporting and recordkeeping requirements, Safety, Space transportation and exploration.</P>
                    <CFR>14 CFR Part 460</CFR>
                    <P>Reporting and recordkeeping requirements, Rockets, Space safety, Space transportation and exploration.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>In consideration of the foregoing, the Federal Aviation Administration proposes to amend 14 CFR as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 3—GENERAL REQUIREMENTS</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 3 is revised to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701-44709, 46111, and 46301.</P>
                </AUTH>
                <AMDPAR>2. Revise § 3.1(a) introductory text to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 3.1</SECTNO>
                    <SUBJECT> Applicability.</SUBJECT>
                    <P>(a) This subpart applies to any person who makes a record regarding:</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>3. Add subpart D, consisting of §§ 3.401, 3.403, and 3.405, to part 3 to read as follows:</AMDPAR>
                <SUBPART>
                    <PRTPAGE P="8576"/>
                    <HD SOURCE="HED">Subpart D—Falsification, Reproduction, Alteration, Omission, or Incorrect Statements</HD>
                </SUBPART>
                <CONTENTS>
                    <SECHD>Sec.</SECHD>
                    <SECTNO>3.401 </SECTNO>
                    <SUBJECT>Applicability.</SUBJECT>
                    <SECTNO>3.403 </SECTNO>
                    <SUBJECT>Falsification, reproduction, alteration, or omission.</SUBJECT>
                    <SECTNO>3.405 </SECTNO>
                    <SUBJECT>Incorrect statement, or omission.</SUBJECT>
                </CONTENTS>
                <SECTION>
                    <SECTNO>§ 3.401</SECTNO>
                    <SUBJECT> Applicability.</SUBJECT>
                    <P>This subpart applies to any person subject to the requirements in subchapter A (except parts 1 and 3), subchapter C (except part 39), subchapter D, subchapter E (except parts 71 and 73), subchapter F (except parts 95 and 97), subchapter G (except part 110), subchapter H, and subchapter K (except parts 185, 187, 189 and 193), of this chapter.</P>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 3.403</SECTNO>
                    <SUBJECT> Falsification, reproduction, alteration, or omission.</SUBJECT>
                    <P>(a) No person may make or cause to be made any fraudulent or intentionally false statement in:</P>
                    <P>(1) Any document in any format, submitted under any provision referenced in § 3.401, consisting of or related to any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, record, report, request for reconsideration, or similar; or</P>
                    <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 3.401.</P>
                    <P>(b) No person may make or cause to be made any production, reproduction, or alteration, for fraudulent purpose, of:</P>
                    <P>(1) Any document in any format, submitted or granted under any provision referenced in § 3.401, consisting of or related to any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, record, report, request for reconsideration, or similar; or</P>
                    <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 3.401.</P>
                    <P>(c) No person may knowingly omit, or cause to be omitted, a material fact in:</P>
                    <P>(1) Any document in any format, submitted under any provision referenced in § 3.401, consisting of or related to any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, record, report, request for reconsideration, or similar; or</P>
                    <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 3.401.</P>
                    <P>(d) The commission by any person of an act prohibited under paragraphs (a) through (c) of this section is a basis for:</P>
                    <P>(1) Denying, suspending, modifying, revoking, rescinding, removing, or withdrawing any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, request for reconsideration, or similar, issued or granted by the Administrator and held by that person; or</P>
                    <P>(2) A civil penalty.</P>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 3.405</SECTNO>
                    <SUBJECT> Incorrect statement, or omission.</SUBJECT>
                    <P>(a) No person may make or cause to be made a material incorrect statement, or omit or cause to be omitted a material fact, in:</P>
                    <P>(1) Any document in any format, submitted under any provision referenced in § 3.401, consisting of or related to any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, record, report, request for reconsideration, or similar; or</P>
                    <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 3.401.</P>
                    <P>(b) A material incorrect statement, or omission of a material fact, in any document described in § 3.405(a)(1) and (2) may serve as a basis for denying, suspending, modifying, revoking, rescinding, removing, or withdrawing any acceptance, application, approval, authorization, certificate, rating, declaration, designation, qualification, request for reconsideration, or similar, issued or granted by the Administrator and held by that person.</P>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 21—CERTIFICATION PROCEDURES FOR PRODUCTS AND ARTICLES</HD>
                </PART>
                <AMDPAR>4. The authority citation for part 21 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 42 U.S.C. 7572; 49 U.S.C. 106(f), 106(g), 40105, 40113, 44701-44702, 44704, 44707, 44709, 44711, 44713, 44715, 45303.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 21.2</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>5. Remove and reserve § 21.2.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 43—MAINTENANCE, PREVENTIVE MAINTENANCE, REBUILDING, AND ALTERATION</HD>
                </PART>
                <AMDPAR>6. The authority citation for part 43 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 42 U.S.C. 7572; 49 U.S.C. 106(f), 106(g), 40105, 40113, 44701-44702, 44704, 44707, 44709, 44711, 44713, 44715, 45303.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 43.12</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>7. Remove and reserve § 43.12.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 60—FLIGHT SIMULATION TRAINING DEVICE INITIAL AND CONTINUING QUALIFICATION AND USE</HD>
                </PART>
                <AMDPAR>8. The authority citation for part 60 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40113, and 44701; Pub. L. 111-216, 124 Stat. 2348 (49 U.S.C. 44701 note).</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 60.33</SECTNO>
                    <SUBJECT> [Removed and Reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>9. Remove and reserve § 60.33.</AMDPAR>
                <HD SOURCE="HD1">Appendix A to Part 60</HD>
                <AMDPAR>10. In Appendix A to part 60:</AMDPAR>
                <AMDPAR>a. In the table of contents, remove and reserve entry 22., and</AMDPAR>
                <AMDPAR>b. Remove and reserve section “22. Applications, Logbooks, Reports, and Records: Fraud, Falsification, or Incorrect Statements (§ 60.33)”</AMDPAR>
                <HD SOURCE="HD1">Appendix B to Part 60</HD>
                <AMDPAR>11. In Appendix B to part 60:</AMDPAR>
                <AMDPAR>a. In the table of contents, remove and reserve entry 22., and</AMDPAR>
                <AMDPAR>b. Remove and reserve section “22. Applications, Logbooks, Reports, and Records: Fraud, Falsification, or Incorrect Statements (§ 60.33).”</AMDPAR>
                <HD SOURCE="HD1">Appendix C to Part 60</HD>
                <AMDPAR>12. In Appendix C to part 60:</AMDPAR>
                <AMDPAR>a. In the table of contents, remove and reserve entry 22., and</AMDPAR>
                <AMDPAR>b. Remove and reserve section “22. Applications, Logbooks, Reports, and Records: Fraud, Falsification, or Incorrect Statements (§ 60.33).”</AMDPAR>
                <HD SOURCE="HD1">Appendix D to Part 60</HD>
                <AMDPAR>13. In Appendix D to part 60:</AMDPAR>
                <AMDPAR>a. In the table of contents, remove and reserve entry 22., and</AMDPAR>
                <AMDPAR>b. Remove and reserve section “22. Applications, Logbooks, Reports, and Records: Fraud, Falsification, or Incorrect Statements (§ 60.33).”</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 61—CERTIFICATION: PILOTS, FLIGHT INSTRUCTORS, AND GROUND INSTRUCTORS</HD>
                </PART>
                <AMDPAR>14. The authority citation for part 61 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>49 U.S.C. 106(f), 106(g), 40113, 44701-44703, 44707, 44709-44711, 44729, 44903, 45102-45103, 45301-45302.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 61.59</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>15. Remove and reserve § 61.59.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 63—CERTIFICATION: FLIGHT CREWMEMBERS OTHER THAN PILOTS</HD>
                </PART>
                <AMDPAR>16. The authority citation for part 63 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40113, 44701-44703, 44707, 44709-44711, 45102-45103, 45301-45302.</P>
                </AUTH>
                <SECTION>
                    <PRTPAGE P="8577"/>
                    <SECTNO>§ 63.20</SECTNO>
                    <SUBJECT>[Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>17. Remove and reserve § 63.20.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 65—CERTIFICATION: AIRMEN OTHER THAN FLIGHT CREWMEMBERS</HD>
                </PART>
                <AMDPAR>18. The authority citation for part 65 continuous to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40113, 44701-44703, 44707, 44709-44711, 45102-45103, 45301-45302.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 65.20</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>19. Remove and reserve § 65.20.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 67—MEDICAL STANDARDS AND CERTIFICATION</HD>
                </PART>
                <AMDPAR>20. The authority citation for part 67 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701-44703, 44707, 44709-44711, 45102-45103, 45301-45303.</P>
                </AUTH>
                <AMDPAR>21. Revise § 67.401(f)(5) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 67.401</SECTNO>
                    <SUBJECT> Special issuance of medical certificates.</SUBJECT>
                    <STARS/>
                    <P>(f) * * *</P>
                    <P>(5) The holder makes or causes to be made a statement or entry that is the basis for withdrawal of an Authorization, including a SODA, under subpart D of part 3 of this chapter.</P>
                    <STARS/>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 67.403</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>22. Remove and reserve § 67.403.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 89—REMOTE IDENTIFICATION OF UNMANNED AIRCRAFT</HD>
                </PART>
                <AMDPAR>23.The authority citation for part 89 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40101(d), 40103(b), 44701, 44805, 44809(f); Section 2202 of Pub. L. 114-190, 130 Stat. 629.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 89.5</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>24. Remove and reserve § 89.5.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 107—SMALL UNMANNED AIRCRAFT SYSTEMS</HD>
                </PART>
                <AMDPAR>25. The authority citation for part 107 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 40101 note, 40103(b), 44701(a)(5), 46105(c), 46110, 44807.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 107.5</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>26. Remove and reserve § 107.5.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 111—PILOT RECORDS DATABASE</HD>
                </PART>
                <AMDPAR>27. The authority citation for part 111 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40101, 40113, 44701, 44703, 44711, 46105, 46301.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 111.35</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>28. Remove and reserve § 111.35.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 120—DRUG AND ALCOHOL TESTING PROGRAM</HD>
                </PART>
                <AMDPAR>29. The authority citation for part 120 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40101-40103, 40113, 40120, 41706, 41721, 44106, 44701, 44702, 44703, 44709, 44710, 44711, 45101-45105, 46105, 46306.</P>
                </AUTH>
                <AMDPAR>30. Remove and reserve § 120.103(e).</AMDPAR>
                <SECTION>
                    <SECTNO>§ 120.213</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>31. Remove and reserve § 120.213.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 121—OPERATING REQUIREMENTS: DOMESTIC, FLAG, AND SUPPLEMENTAL OPERATIONS</HD>
                </PART>
                <AMDPAR>32. The authority citation for part 121 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>49 U.S.C. 106(f), 106(g), 40103, 40113, 40119, 41706, 42301 preceding note added by Pub. L. 112-95, sec. 412, 126 Stat. 89, 44101, 44701-44702, 44705, 44709-44711, 44713, 44716-44717, 44722, 44729, 44732; 46105; Pub. L. 111-216, 124 Stat. 2348 (49 U.S.C. 44701 note); Pub. L. 112-95, 126 Stat. 62 (49 U.S.C. 44732 note); Pub. L. 115-254, 132 Stat. 3186 (49 U.S.C. 44701 note).</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 121.9</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>33. Remove and reserve § 121.9.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 139—CERTIFICATION OF AIRPORTS</HD>
                </PART>
                <AMDPAR>34. The authority citation for part 139 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40113, 44701-44706, 44709, 44719, 47175.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 139.115</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>35. Remove and reserve § 139.115.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 142—TRAINING CENTERS</HD>
                </PART>
                <AMDPAR>36. The authority citation for part 142 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g), 40113, 40119, 44101, 44701-44703, 44705, 44707, 44709-44711, 45102-45103, 45301-45302.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 142.11</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>37. Remove and reserve § 142.11(e)(3).</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 145—REPAIR STATIONS</HD>
                </PART>
                <AMDPAR>38. The authority citation for part 145 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701-44702, 44707, 44709, 44717.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 145.12</SECTNO>
                    <SUBJECT> [Removed and reserved]</SUBJECT>
                </SECTION>
                <AMDPAR>39. Remove and reserve § 145.12.</AMDPAR>
                <AMDPAR>40. Add part 402 to subchapter A to read as follows:</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 402—GENERAL REQUIREMENTS</HD>
                    <CONTENTS>
                        <SECHD>Sec.</SECHD>
                        <SECTNO>402.1 </SECTNO>
                        <SUBJECT>Applicability.</SUBJECT>
                        <SECTNO>402.3 </SECTNO>
                        <SUBJECT>Falsification, reproduction, alteration, or omission.</SUBJECT>
                        <SECTNO>402.5 </SECTNO>
                        <SUBJECT>Incorrect statement, or omission.</SUBJECT>
                    </CONTENTS>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 51 U.S.C. 50101-50923.</P>
                    </AUTH>
                    <SECTION>
                        <SECTNO>§ 402.1</SECTNO>
                        <SUBJECT> Applicability.</SUBJECT>
                        <P>This part applies to any person subject to the requirements in subchapter C of this chapter.</P>
                    </SECTION>
                    <SECTION>
                        <SECTNO>§ 402.3</SECTNO>
                        <SUBJECT> Falsification, reproduction, alteration, or omission.</SUBJECT>
                        <P>(a) No person may make or cause to be made any fraudulent or intentionally false statement in:</P>
                        <P>(1) Any document in any format, submitted under any provision referenced in § 402.1 of this part, consisting of or related to any acceptance, application, approval, authorization, permit, license, waiver, record, report, or similar; or</P>
                        <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 402.1.</P>
                        <P>(b) No person may make or cause to be made any production, reproduction or alteration, for fraudulent purpose, of:</P>
                        <P>(1) Any document in any format, submitted or granted under any provision referenced in § 402.1, consisting of or related to any acceptance, application, approval, authorization, permit, license, waiver, record, report, or similar; or</P>
                        <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 402.1.</P>
                        <P>(c) No person may knowingly omit or cause to be omitted a material fact in:</P>
                        <P>(1) Any document in any format, submitted under any provision referenced in § 402.1, consisting of or related to any acceptance, application, approval, authorization, permit, license, waiver, record, report, or similar; or</P>
                        <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 402.1.</P>
                        <P>(d) The commission by any person of an act prohibited under paragraphs (a) through (c) of this section is a basis for:</P>
                        <P>(1) Denying, suspending, modifying, revoking, rescinding, removing, or withdrawing any acceptance, application, approval, authorization, permit, license, waiver, or similar, issued or granted by the Administrator and held by that person; or</P>
                        <P>(2) A civil penalty.</P>
                    </SECTION>
                    <SECTION>
                        <PRTPAGE P="8578"/>
                        <SECTNO>§ 402.5</SECTNO>
                        <SUBJECT> Incorrect statement, or omission.</SUBJECT>
                        <P>(a) No person may make or cause to be made a material incorrect statement, or omit or cause to be omitted a material fact, in:</P>
                        <P>(1) Any document in any format, submitted under any provision referenced in § 402.1, consisting of or related to any acceptance, application, approval, authorization, permit, license, waiver, record, report, or similar; or</P>
                        <P>(2) Any document in any format that is kept, made, or used to show compliance with any requirement under the provisions referenced in § 402.1.</P>
                        <P>(b) A material incorrect statement, or omission of a material fact, in a document described in § 402.5(a)(1) and (2) may serve as a basis for denying, suspending, modifying, revoking, rescinding, removing, or withdrawing any acceptance, application, approval, authorization, permit, license, waiver, or similar, issued or granted by the Administrator and held by that person.</P>
                    </SECTION>
                </PART>
                <PART>
                    <HD SOURCE="HED">PART 413—LICENSE APPLICATION PROCEDURES</HD>
                </PART>
                <AMDPAR>41. The authority citation for part 413 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 51 U.S.C. 50901-50923.</P>
                </AUTH>
                <AMDPAR>42. Remove and reserve § 413.17(c).</AMDPAR>
                <P>Issued under authority provided by 49 U.S.C. 106(f), 44701(a), and 44703 in Washington, DC.</P>
                <SIG>
                    <NAME>Marc A. Nichols,</NAME>
                    <TITLE>Chief Counsel.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00872 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL TRADE COMMISSION</AGENCY>
                <CFR>16 CFR Part 1</CFR>
                <RIN>RIN 3084-AB79</RIN>
                <SUBJECT>Horseracing Integrity and Safety Authority Oversight</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Trade Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rule; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Federal Trade Commission (“FTC” or “Commission”) announces proposed rules regarding oversight of the Horseracing Integrity and Safety Authority (“Authority”). The proposed rules include new oversight provisions to ensure that the Authority remains publicly accountable and operates in a fiscally prudent, safe, and effective manner.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by April 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested parties may file a comment online or on paper by following the instructions in the Request for Comment part of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section below. Write “HISA Oversight Rulemaking, Matter No. P222100” on your comment and file your comment online at 
                        <E T="03">https://www.regulations.gov</E>
                         by following the instructions on the web-based form. If you prefer to file your comment on paper, mail your comment to the following address: Federal Trade Commission, Office of the Secretary, 600 Pennsylvania Avenue NW, Mail Stop H-144 (Annex H), Washington, DC 20580.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sarah Botha (202-326-2036, 
                        <E T="03">sbotha@ftc.gov</E>
                        ), Office of the Executive Director, Federal Trade Commission.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    The Horseracing Integrity and Safety Act of 2020 (“HISA” or “the Act”), Public Law 116-260, Title XII, 134 Stat 1182, 3252 (2020) (codified as amended at 15 U.S.C. 3051-3060), recognizes the Authority as a self-regulatory nonprofit organization charged with developing and enforcing rules relating to racetrack safety, anti-doping, and medication control. 
                    <E T="03">See</E>
                     15 U.S.C. 3052. The Act expressly provides for Commission oversight of several aspects of the Authority's operations. For example, the Commission must approve any proposed rule or rule modification by the Authority relating to the Authority's bylaws, racetrack safety standards, anti-doping and medication control, and the formula or methodology for determining assessments. 
                    <E T="03">See id.</E>
                     In December 2022, Congress amended HISA to expand the Commission's oversight role over the Authority. 
                    <E T="03">See</E>
                     Consolidated Appropriations Act, 2023, Public Law 117-328, Sec. 701, 136 Stat. 4459, 5231 (2022). As amended, the Act gives the Commission the power to issue rules under the procedures set forth in the Administrative Procedure Act, 5 U.S.C. 553, “as the Commission finds necessary or appropriate to ensure the fair administration of the Authority . . . or otherwise in furtherance of the purposes of this Act.” 15 U.S.C. 3053(e).
                </P>
                <P>In light of the Commission's experience in overseeing the Authority's operations to date, the Commission is exercising its rulemaking authority to propose several new rule provisions to ensure effective Commission oversight over the Authority. The proposed new provisions are designed to ensure that the Authority is promoting transparency and integrity in its operations. For example, new rule sections would require the Authority to submit and publish annual and midyear reports about its performance and financial position. The proposed rules would also require the Authority to develop, maintain, and publish a multi-year strategic plan, after taking public comments on the draft plan. The proposed rules would require the Authority to effectively manage risk and take steps to prevent conflicts of interest, waste, fraud, embezzlement, and abuse. The proposed rules would also mandate other operational requirements and identify best practices for the Authority to follow, as explained in the section-by-section analysis below. The Commission would add the proposed new rules as 16 CFR 1.153 through 1.156 in Subpart U of part 1 of its Rules of Practice. Subpart U would be renamed “Oversight of the Horseracing Integrity and Safety Authority” to reflect more accurately the content of the amended subpart.</P>
                <HD SOURCE="HD1">Section by Section Analysis</HD>
                <P>
                    <E T="03">§ 1.153 Submission of the Authority's annual reports, midyear reports, and strategic plans.</E>
                     This proposed new section imposes certain requirements on the Authority to report on its finances for the preceding calendar year by May 15. This includes a complete accounting of the Authority's budget (as audited by a qualified, independent, registered public accounting firm and in accordance with Generally Accepted Accounting Principles), a discussion of budgetary line items, a summary of travel expenses, and a summary of any new or continuing risks or issues raised by audits or other reviews. The proposed section also imposes certain requirements on the Authority to report by March 31 on its performance for the prior calendar year, with such report to include efforts made to carry out the requirements of the Act, a description of the cooperation with the states as set forth in 15 U.S.C. 3060(b), a summary of final civil sanctions, an assessment of the Authority's progress in meeting or not meeting its performance measures contained in its strategic plan per § 1.153(d), a summary of Board of Directors committee recommendations and activities, information about any changes in the composition of the Authority's Board of Directors or standing committees, information about the relationship between the Authority and the anti-doping and medication control enforcement agency, a summary of all litigation to which the Authority is a party (including actions commenced by the Authority under 15 U.S.C. 3054(j)), a summary of all subpoenas issued by the Authority under 15 U.S.C. 
                    <PRTPAGE P="8579"/>
                    3054(c), a description of any areas in which the Authority believes improvements to its operations are warranted, and the Authority's plans to achieve those improvements. The proposed section also requires the Authority to submit to the FTC by August 15 a same year midyear report covering January to June that describes spending and staffing levels and budgetary information. This midyear report would provide operational insight about the Authority's budget execution and risk management activities. Under the proposed section, the Authority also must develop and publish for public comment a multi-year strategic plan by June 30, 2024. The Authority must re-evaluate its strategic plan no less frequently than every five years. The strategic plan must align with the Authority's annual budget, discuss its priority initiatives, and set forth a set of performance measures. The Authority must publish its annual financial reports, annual performance reports, and strategic plans on its website.
                </P>
                <P>
                    <E T="03">§ 1.154 Enterprise risk management.</E>
                     This proposed new section imposes certain requirements on the Authority to ensure that it effectively manages risk to prevent conflicts of interest, waste, fraud, embezzlement, or abuse. Paragraph (a) sets forth guiding principles around separation of duties and corrective action plans, and notes that risk management activities must ensure compliance, the avoidance of conflicts of interest or the appearance thereof, and the appropriate handling of funds received and expended by the Authority. Given the confidential nature of much of the Authority's work and the data that it collects, paragraph (b) would require the Authority to ensure the privacy and security of its data in its systems, including those operated by third-party contractors, and require a complete annual evaluation of the status of its overall information technology program and practices as audited by a qualified, independent, third-party auditor. Given that the Authority leverages contractor resources in its operations, paragraph (c) would require the Authority to document its market research for any action estimated at over $10,000 to ensure the lowest cost or best value for goods and services to be provided, and to develop policies and procedures covering procurement activities. Given the FTC's need for regular communication and awareness of the Authority's activities, paragraph (d) would require the Authority to provide advance notice to Commission staff of all significant Authority-planned events (
                    <E T="03">e.g.,</E>
                     press conferences, media events, summits, etc.) via a calendar, list, email, or other reasonable means, to summarize key aspects of all such events on its website, and to give Commission staff prompt notice after significant adverse events in the horseracing industry that might reasonably lead to sanctions or track closures.
                </P>
                <P>
                    <E T="03">§ 1.155 Other best practices.</E>
                     This proposed new section includes a set of best practices that the Authority is encouraged to adopt to promote accountability, transparency of operations, and effective resource stewardship. These proposals include holding regular monitoring meetings with the FTC; recommendations for how the Authority may maintain its records and information; recommendations for how the Authority should treat confidential information; a standing data request from the FTC for the Authority's Board of Directors minutes; recommendations about the Authority's personnel and compensation policies and practices; recommendations about the Authority's customer service program (and the development of associated metrics); and recommendations regarding the Authority's travel policies.
                </P>
                <P>
                    <E T="03">§ 1.156 Severability.</E>
                     This proposed new section notes that provisions of this subpart are separate and severable from one another. If any provision is stayed or determined to be invalid, it is the Commission's intention that the remaining provisions shall continue in effect.
                </P>
                <HD SOURCE="HD1">Request for Comment</HD>
                <P>
                    You can file a comment online or on paper. For the Commission to consider your comment, we must receive it on or before April 8, 2024. Write “HISA Oversight Rulemaking, Matter No. P222100” on your comment. Your comment—including your name and your state—will be placed on the public record of this proceeding, including the 
                    <E T="03">https://www.regulations.gov</E>
                     website.
                </P>
                <P>
                    Postal mail addressed to the Commission is subject to delay due to heightened security screening. As a result, we strongly encourage you to submit your comments online. To make sure the Commission considers your online comment, you must file it at 
                    <E T="03">https://www.regulations.gov,</E>
                     by following the instructions on the web-based form.
                </P>
                <P>If you file your comment on paper, write “HISA Oversight Rulemaking, Matter No. P222100” on your comment and on the envelope, and mail your comment to the following address: Federal Trade Commission, Office of the Secretary, 600 Pennsylvania Avenue NW, Mail Stop H-144 (Annex H), Washington, DC 20580. If possible, submit your paper comment to the Commission by overnight service.</P>
                <P>
                    Because your comment will be placed on the publicly accessible website at 
                    <E T="03">https://www.regulations.gov,</E>
                     you are solely responsible for making sure your comment does not include any sensitive or confidential information. In particular, your comment should not include any sensitive personal information, such as your or anyone else's Social Security number; date of birth; driver's license number or other state identification number, or foreign country equivalent; passport number; financial account number; or credit or debit card number. You are also solely responsible for making sure your comment does not include any sensitive health information, such as medical records or other individually identifiable health information. In addition, your comment should not include any “any trade secret or any commercial or financial information . . . which is privileged or confidential.” 15 U.S.C. 46(f); 
                    <E T="03">see</E>
                     FTC Rule 4.10(a)(2), 16 CFR 4.10(a)(2). In particular, your comment should not include competitively sensitive information such as costs, sales statistics, inventories, formulas, patterns, devices, manufacturing processes, or customer names.
                </P>
                <P>
                    Comments containing material for which confidential treatment is requested must be filed in paper form, must be clearly labeled “Confidential,” and must comply with FTC Rule 4.9(c), 16 CFR 4.9(c). In particular, the written request for confidential treatment that accompanies the comment must include the factual and legal basis for the request and must identify the specific portions of the comment to be withheld from the public record. 
                    <E T="03">See</E>
                     FTC Rule 4.9(c), 16 CFR 4.9(c). Your comment will be kept confidential only if the General Counsel grants your request in accordance with the law and the public interest. Once your comment has been posted publicly at 
                    <E T="03">https://www.regulations.gov,</E>
                     as legally required by FTC Rule 4.9(b), 16 CFR 4.9(b), we cannot redact or remove your comment, unless you submit a confidentiality request that meets the requirements for such treatment under FTC Rule 4.9(c), 16 CFR 4.9(c), and the General Counsel grants that request.
                </P>
                <P>
                    Visit the FTC website to read this document and the news release describing it and visit 
                    <E T="03">https://www.regulations.gov/docket/FTC-2024-0012</E>
                     to read a plain-language summary of the proposed rule. The FTC Act and other laws that the Commission 
                    <PRTPAGE P="8580"/>
                    administers permit the collection of public comments to consider and use in this proceeding as appropriate. The Commission will consider all timely and responsive public comments that it receives on or before April 8, 2024. For information on the Commission's privacy policy, including routine uses permitted by the Privacy Act, see 
                    <E T="03">https://www.ftc.gov/site-information/privacy-policy.</E>
                </P>
                <HD SOURCE="HD1">Paperwork Reduction Act</HD>
                <P>
                    The Paperwork Reduction Act (“PRA”), 44 U.S.C. chapter 35, requires federal agencies to seek and obtain Office of Management and Budget approval before undertaking a collection of information directed to ten or more persons. Under the PRA, a rule creates a “collection of information” when ten or more persons are asked to report, provide, disclose, or record information in response to “identical questions.” 
                    <SU>1</SU>
                    <FTREF/>
                     The Commission concludes that the PRA does not apply to the proposed amendments because they only apply to one “person,” the Authority.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         44 U.S.C. 3502(3)(A).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Regulatory Flexibility Act</HD>
                <P>
                    The Regulatory Flexibility Act (“RFA”), as amended by the Small Business Regulatory Enforcement Fairness Act of 1996, requires an agency to either provide an Initial Regulatory Flexibility Analysis with a proposed rule, or certify that the proposed rule will not have a significant impact on a substantial number of small entities.
                    <SU>2</SU>
                    <FTREF/>
                     The RFA defines a “small entity” as a small business, a small governmental jurisdiction, or a small not-for-profit organization. 
                    <E T="03">See</E>
                     5 U.S.C. 601(6).
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         5 U.S.C. 603-605.
                    </P>
                </FTNT>
                <P>
                    The proposed amendments would apply only to the Authority, and the Authority is not a small business or a small governmental jurisdiction. While the Authority is a nonprofit entity, it is not a small not-for-profit organization, defined in the RFA as “any not-for-profit enterprise which is independently owned and operated and is not dominant in its field.” 
                    <E T="03">Id.</E>
                     601(5). The authority is not “independently owned and operated,” and it is dominant in its field. The Commission therefore certifies under the RFA that the proposed rule will not have a significant impact on a substantial number of small entities, and hereby provides notice of that certification to the Small Business Administration.
                </P>
                <HD SOURCE="HD1">Communications by Outside Parties to Commissioners or Their Advisors</HD>
                <P>
                    Written communications and summaries or transcripts of oral communications respecting the merits of this proceeding, from any outside party to any Commissioner or a Commissioner's advisor, will be placed on the public record. 
                    <E T="03">See</E>
                     16 CFR 1.26(b)(5).
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 16 CFR Part 1</HD>
                    <P>Administrative practice and procedure; Animal welfare; Animal drugs.</P>
                </LSTSUB>
                <P>For the reasons set forth in the preamble, the Federal Trade Commission proposes to amend title 16, chapter I, subchapter A of the Code of Federal Regulations as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 1—GENERAL PROCEDURES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 1 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>15 U.S.C. 46; 15 U.S.C. 57a; 5 U.S.C. 552; 5 U.S.C. 601 note.</P>
                </AUTH>
                <AMDPAR>2. Add §§ 1.153 through 1.156 to subpart U to read as follows:</AMDPAR>
                <SUBPART>
                    <HD SOURCE="HED">Subpart U—Oversight of the Horseracing Integrity and Safety Authority</HD>
                </SUBPART>
                <CONTENTS>
                    <SECHD>Sec.</SECHD>
                    <STARS/>
                    <SECTNO>153</SECTNO>
                    <SUBJECT>Submission of the Authority's annual reports, midyear reports, and strategic plans.</SUBJECT>
                    <SECTNO>1.154 </SECTNO>
                    <SUBJECT>Enterprise risk management.</SUBJECT>
                    <SECTNO>1.155 </SECTNO>
                    <SUBJECT>Other best practices.</SUBJECT>
                    <SECTNO>1.156 </SECTNO>
                    <SUBJECT>Severability.</SUBJECT>
                </CONTENTS>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>15 U.S.C. 3053(e).</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 1.153 </SECTNO>
                    <SUBJECT>Submission of the Authority's annual reports, midyear reports, and strategic plans.</SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Annual financial report.</E>
                         Every year, by May 15, the Authority must follow the procedures in § 1.143 to submit an annual financial report to the Commission, detailing the items listed below for the previous calendar year. The Authority must also publish this report on its website. The report must contain:
                    </P>
                    <P>(1) A complete accounting of the Authority's budget, as audited by a qualified, independent, registered public accounting firm and in accordance with Generally Accepted Accounting Principles (including a statement from the auditor attesting to the auditor's independence and its opinion regarding the financial statements presented in the annual financial report);</P>
                    <P>(2) Line-item comparisons between the approved budget's revenues and expenditures for the previous year and the actual revenues and expenditures for the previous year;</P>
                    <P>(3) An explanation of how the Authority has considered the relative costs and benefits in formulating the programs, projects, and activities described in the budget;</P>
                    <P>(4) A description and accounting of the Authority's insurance coverage;</P>
                    <P>(5) A description and accounting of any budgetary reserves;</P>
                    <P>(6) Summaries of contracts or other liabilities that the Authority has entered into or may potentially incur;</P>
                    <P>(7) A summary of travel expenses, including an itemized list of any first-class travel (defined as the highest and most expensive class of service);</P>
                    <P>
                        (8) Any new or continuing material or significant risks or issues raised by the audit, internal quality or control reviews, other inspections or peer reviews of the Authority, or any inquiry or investigation by governmental or professional authorities, along with any steps taken (
                        <E T="03">e.g.,</E>
                         corrective actions) to deal with any such issues, consistent with § 1.154; and
                    </P>
                    <P>(9) Any other information requested by Commission staff.</P>
                    <P>
                        (b) 
                        <E T="03">Annual performance report.</E>
                         Every year, by March 31, the Authority must follow the procedures in § 1.143 to submit an annual performance report to the Commission, detailing the items listed below for the previous calendar year. The Authority must also publish this report on its website. The report must contain:
                    </P>
                    <P>(1) Narrative summaries of all the major efforts by the Authority to carry out the requirements of the Act, including the status or results of any publicly announced investigations conducted by the Authority;</P>
                    <P>(2) Information about the Authority's cooperation with the States as set forth in 15 U.S.C. 3060(b), including whether each State has covered horseraces, elects to remit fees, or has entered into an agreement under 15 U.S.C. 3060(a)(1) to implement a component of the programs on racetrack safety or anti-doping and medication control;</P>
                    <P>
                        (3) A summary of all final civil sanctions imposed by the Authority in the previous year, in a tabular format; at a minimum, the summary should be broken down by violation category 
                        <E T="03">(e.g.,</E>
                         racetrack safety program, anti-doping and controlled medication protocol rules, etc.) and should include the total number of alleged violations by category, the number of times the violations were admitted and resolved without adjudication, the number of times any violations were contested and adjudicated, the number of times any 
                        <PRTPAGE P="8581"/>
                        sanctions were imposed, the number of times that no sanctions were imposed, the number of civil sanction notices that needed to be reissued or corrected, the total fines imposed, the total amount of purses forfeited, and the number of times the sanctions were appealed to the Commission's Administrative Law Judge;
                    </P>
                    <P>(4) An assessment of the Authority's progress in meeting or not meeting its performance measures contained in its Strategic plan per § 1.153(d);</P>
                    <P>(5) A statement from each Board of Directors committee summarizing its work in the previous year and all recommendations each such committee has made to the Board;</P>
                    <P>(6) Information about any changes in the composition of the Authority's Board of Directors or standing committees;</P>
                    <P>(7) Information about the relationship between the Authority and the anti-doping and medication control enforcement agency, including how the enforcement agency is performing under its contract with the Authority and how many years remain under the contract;</P>
                    <P>(8) A summary of all litigation to which the Authority is a party, including actions commenced by the Authority under 15 U.S.C. 3054(j);</P>
                    <P>(9) A summary of all subpoenas issued by the Authority under 15 U.S.C. 3054(c);</P>
                    <P>(10) Descriptions of any areas in which the Authority believes that improvements to its operations are warranted, together with the Authority's plans to achieve those improvements. Forward-looking information should reflect known and anticipated risks, uncertainties, future events or conditions, and trends that could significantly affect the Authority's future financial position, condition, or operating performance, as well as Authority actions that have been planned or taken to address those challenges; and</P>
                    <P>(11) Any other information requested by Commission staff.</P>
                    <P>
                        (c) 
                        <E T="03">Midyear reporting.</E>
                         By August 15, the Authority must furnish to the Commission a same-year midyear report covering January through June, to include:
                    </P>
                    <P>(1) Spending and staffing levels for the quarter ending June 30, compared to the levels in the Commission-approved budget;</P>
                    <P>(2) A summary of travel expenses, including an itemized list of any first-class travel (defined as the highest and most expensive class of service);</P>
                    <P>(3) The status of outstanding and completed corrective actions; and</P>
                    <P>(4) Any other information requested by Commission staff.</P>
                    <P>
                        (d) 
                        <E T="03">Strategic plan.</E>
                         The Authority must develop and maintain a multiyear strategic plan. The Authority must submit its first strategic plan to the Commission on or before June 30, 2024. The Authority must reevaluate the strategic plan no less frequently than every five years. The Authority's annual budget must align with, and link spending to, the strategic goals. The strategic plan must include items such as a description of its State-by-State relationships and a discussion of planned rulemaking activities. The Authority must:
                    </P>
                    <P>(1) Post its draft strategic plan on its website for a public comment period of at least 14 days;</P>
                    <P>(2) Present its final strategic plan to the Commission, along with a summary of its responses to public comments; and</P>
                    <P>(3) Publish its final strategic plan on its website.</P>
                    <P>
                        (e) 
                        <E T="03">Further guidance on strategic plan.</E>
                         The Authority's strategic plan should include forecasts of the Authority's industry environment and its priority initiatives for the current and subsequent years. The strategic plan should also consider the impact that program levels and changes in methods of program delivery, including advances in technology, could have on program operations and administration. The Strategic Plan should identify several strategic goals aligned with the Authority's mission statement. Each strategic goal should have accompanying objectives, strategies, and performance measures. As guiding principles, performance measures should:
                    </P>
                    <P>(1) Be limited to the vital few and demonstrate results;</P>
                    <P>(2) Cover multiple priorities; and</P>
                    <P>(3) Provide useful information for decision-making.</P>
                    <P>(4) Be clear, measurable, objective, and reliable; and</P>
                    <P>(5) Focus on core program activities and priorities.</P>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 1.154 </SECTNO>
                    <SUBJECT>Enterprise risk management.</SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Guiding principles.</E>
                         The Authority must effectively manage risk to prevent conflicts of interest, waste, fraud, embezzlement, and abuse. To manage risk, the Authority must align the enterprise risk-management process to the goals and objectives noted in the Authority's strategic plan. The Authority must assess risks, select risk responses, monitor whether responses are successful, and communicate and report on risks, consistent with § 1.153. The Authority must ensure that all internal controls have appropriate separation of duties (
                        <E T="03">e.g.,</E>
                         requester, approver, recorder). In addition, the Authority must develop corrective action plans no later than 90 days after receiving a notice of finding from its auditors or other internal assessments. The Board of Directors (or one of the standing committees) must review and evaluate identified risks and proposed corrective action plans. The Authority must review regularly its corrective actions identified from all audits and internal assessments and should develop criteria by which to prioritize its response activities. The Authority must ensure that its risk management activities encompass:
                    </P>
                    <P>(1) Compliance with applicable laws, rules, and regulations;</P>
                    <P>(2) The avoidance of conflicts of interest, or the appearance thereof, in all aspects of the Authority's operations, including investigation and enforcement, vendor selection, personnel assignments and responsibilities, and actions by the Board of Directors or management; and</P>
                    <P>(3) Handling funds received and expended by the Authority, including revenue/expense policies, fundraising practices, contracting policies, travel policies, and real and personal property agreements and expenses.</P>
                    <P>
                        (b) 
                        <E T="03">Data security and privacy.</E>
                         The Authority must ensure the privacy and security of data, including all reasonable measures to protect the confidentiality of any sensitive health information (SHI), personally identifiable Information (PII), and sensitive PII (SPII) stored in its systems, including those operated by the anti-doping and medication control program, the Horseracing Integrity and Welfare Unit, and the Authority's third-party contractors. The Authority must ensure a complete annual evaluation of the status of its overall information technology security program and practices, as audited by a qualified, independent, third-party auditor. The Authority must also ensure that it has policies, programs, and practices in place to protect SHI, PII, and SPII. The Authority must send a copy of the annual evaluation to Commission staff.
                    </P>
                    <P>
                        (c) 
                        <E T="03">Vendor selection.</E>
                         Procurement actions estimated at over $10,000 must be accompanied by documented market research (
                        <E T="03">e.g.,</E>
                         comparing the prices and other terms offered by the selected vendor against the prices and other terms offered by at least two other vendors) to ensure lowest cost or best value for goods or services to be provided. The Authority should also develop policies and procedures covering procurement activities.
                        <PRTPAGE P="8582"/>
                    </P>
                    <P>
                        (d) 
                        <E T="03">Notice.</E>
                         The Authority must provide advance notice to Commission staff of all significant Authority-planned events (
                        <E T="03">e.g.,</E>
                         press conferences, media events, summits, etc.) via a calendar, a list, email, or some other reasonable means. The Authority must also summarize key aspects of all such events on its website within a reasonable timeframe. The Authority must also give Commission staff prompt notice after it has been alerted to significant, adverse events in the horseracing industry (
                        <E T="03">e.g.,</E>
                         adverse safety or medical events that might reasonably lead to sanctions, track closures, etc.).
                    </P>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 1.155 </SECTNO>
                    <SUBJECT>Other best practices.</SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Regular monitoring meetings.</E>
                         The Commission recommends that the Authority hold regular meetings with Commission staff to discuss upcoming or potential risks, challenges, and opportunities for improvement.
                    </P>
                    <P>
                        (b) 
                        <E T="03">Records and information management.</E>
                         The Commission recommends that the Authority maintain records and information in sufficient detail to support the Authority's programs and operations, as well as any records relating to its information management policies or procedures. The Commission expects that the Authority will make any of these records available to Commission staff upon request, to allow the Commission to carry out its statutorily mandated oversight.
                    </P>
                    <P>
                        (c) 
                        <E T="03">Treatment of confidential information.</E>
                         The Commission recommends that the Authority's submissions to the Commission not include any SHI, PII, or SPII, such as a Social Security number; date of birth; driver's license number or other state identification number, or foreign country equivalent; passport number; financial account number; or credit or debit card number. If the Authority submits documents to the Commission containing confidential commercial or financial information, it should so designate that material and request confidential treatment pursuant to § 4.10(g).
                    </P>
                    <P>
                        (d) 
                        <E T="03">Standing data requests.</E>
                         The Commission recommends that the Authority submit Board of Directors minutes to the Commission's Office of the Secretary within 15 days following each Board meeting.
                    </P>
                    <P>
                        (e) 
                        <E T="03">Personnel and compensation.</E>
                         The Commission recommends that the Authority develop compensation policies and practices with the primary objective of attracting, developing, and retaining high-performing individuals capable of achieving the Authority's mission. The Authority should strive to recruit a diverse team of industry leaders whose unique backgrounds, education, cultures, and perspectives help position the Authority as an effective and innovative self-regulatory organization. The Commission also recommends that the Authority conduct periodic salary benchmarks to ensure that employee compensation is in line with other like organizations.
                    </P>
                    <P>
                        (f) 
                        <E T="03">Customer service.</E>
                         The Commission recommends that the Authority maintain publicly accessible points of contact (
                        <E T="03">e.g.,</E>
                         email addresses, phone numbers) and monitor the timeliness with which it responds to inquiries. In this regard, the Commission urges the Authority to develop a policy and associated metrics covering its customer service activities, to be incorporated into its strategic plan and its regular reporting to the Commission.
                    </P>
                    <P>
                        (g) 
                        <E T="03">Travel.</E>
                         The Commission recommends that the Authority use standard, GSA-established, published per diem rates when determining how much a person may spend on lodging, meals, and incidental expenses. Nevertheless, actual subsistence expenses may be authorized under unusual circumstances with justification and prior approval from the appropriate approving official. The Commission urges the Authority to prohibit the use of first-class travel (defined as the highest and most expensive class of service) by employees, except when no other option is available or when a disability or exceptional security conditions require it. The Commission also recommends that the Authority not reimburse its contractors for first-class travel unless exceptional circumstances warrant.
                    </P>
                </SECTION>
                <SECTION>
                    <SECTNO>§ 1.156 </SECTNO>
                    <SUBJECT>Severability.</SUBJECT>
                    <P>The provisions of this Subpart are separate and severable from one another. If any provision is stayed or determined to be invalid, it is the Commission's intention that the remaining provisions shall continue in effect.</P>
                </SECTION>
                <SIG>
                    <P>By direction of the Commission,</P>
                    <NAME>Joel Christie,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02291 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6750-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">CONSUMER PRODUCT SAFETY COMMISSION</AGENCY>
                <CFR>16 CFR Part 1264</CFR>
                <DEPDOC>[Docket No. CPSC-2011-0074]</DEPDOC>
                <SUBJECT>Safety Standard Addressing Blade-Contact Injuries on Table Saws; Notice of Opportunity for Oral Presentations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Consumer Product Safety Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Supplemental notice of proposed rulemaking; opportunity for oral presentations.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Consumer Product Safety Commission (Commission or CPSC) will be providing an opportunity for interested parties to make oral presentations on the supplemental notice of proposed rulemaking (SNPR) the Commission issued regarding a safety standard addressing blade-contact injuries on table saws. Presentations will be part of the rulemaking record.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>A hybrid hearing will be held in person at CPSC's headquarters and remotely via webinar and will begin at 10 a.m. Eastern Standard Time (EST) on February 28, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This hearing will be held as a hybrid hearing—in person at CPSC's headquarters and remotely via webinar. For individuals attending in person, the meeting will be held at CPSC's headquarters, located at 4330 East West Highway, 4th Floor—Hearing Room, Bethesda, MD 20814. Individuals who plan to attend the meeting remotely should pre-register for the webinar at 
                        <E T="03">https://cpsc.webex.com/cpsc/j.php?MTID=mdfe71b8646e635c40558465d1e662089.</E>
                         Attendance is free of charge. After registering, you will receive a confirmation email containing information about joining the webinar. In person attendees do not need to register for the hearing. Requests to make oral presentations (in person or remotely) and the text of oral presentations and written comments should be sent by email to: 
                        <E T="03">cpsc-os@cpsc.gov,</E>
                         with the subject line, “Table Saws SNPR; Oral Presentation.” Requests to make oral presentations—in person or remotely—and the written text of any oral presentations must be received by the Office of the Secretary not later than 5 p.m. EST on February 21, 2024. The Commission will accept written comments as well. These also must be received by the Office of the Secretary not later than 5 p.m. EST on February 21, 2024.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For information about the subject matter of this hearing, contact Caroleene Paul, 
                        <PRTPAGE P="8583"/>
                        Director, Mechanical Engineering Division, Consumer Product Safety Commission, 5 Research Place, Rockville, MD 20850; email: 
                        <E T="03">cpaul@cpsc.gov.</E>
                         For information about the procedure to make an oral presentation, contact Alberta E. Mills, Office of the Secretary, Consumer Product Safety Commission, 4330 East-West Highway, Bethesda, MD 20814; 
                        <E T="03">cpsc-os@cpsc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">
                    I. Background 
                    <E T="51">1</E>
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The Commission voted unanimously to publish this notice.
                    </P>
                </FTNT>
                <P>
                    On November 1, 2023, the Commission published an SNPR in the 
                    <E T="04">Federal Register</E>
                    , proposing to issue a safety standard addressing blade-contact injuries on table saws under the Consumer Product Safety Act (CPSA; 15 U.S.C. 2051-2089), and seeking written comments. 88 FR 74909. To address the risk of blade-contact injuries on table saws, the Commission proposes a rule that would establish a performance standard that requires table saws to limit the depth of cut to no more than 3.5 millimeters when a test probe, acting as surrogate for a human finger or other body part, approaches the spinning blade at a rate of 1 meter per second (m/s). The SNPR is available at: 88 FR 74909—Safety Standard Addressing Blade-Contact Injuries on Table Saws—Content Details—2023-23898 (
                    <E T="03">govinfo.gov</E>
                    ), and CPSC staff's briefing package for the SNPR is available at: 
                    <E T="03">https://www.cpsc.gov/s3fs-public/Federal-Register-Notice-Safety-Standard-Addressing-Blade-Contact-Injuries-on-Table-Saws-SNPR.pdf?VersionId=Ce3FOVBmbG0_.8j.gd1h0k3VWHZZ.URw.</E>
                </P>
                <HD SOURCE="HD1">II. The Public Hearing</HD>
                <P>
                    The Administrative Procedure Act (5 U.S.C. 551-562) and section 9 of the CPSA require the Commission to provide interested parties with an opportunity to submit “written data, views, or arguments” regarding a proposed rule. 5 U.S.C. 553(c); 15 U.S.C. 2058(d)(2). The SNPR invited such written comments. In addition, section 9 of the CPSA requires the Commission to provide interested parties “an opportunity for oral presentation of data, views, or arguments.” 15 U.S.C. 2058(d)(2). The Commission must keep a transcript of such oral presentations. 
                    <E T="03">Id.</E>
                     In accordance with this requirement, the Commission is providing a forum for oral presentations concerning the proposed standard.
                </P>
                <P>
                    To request the opportunity to make an oral presentation, see the information under the 
                    <E T="02">DATES</E>
                     and 
                    <E T="02">ADDRESSES</E>
                     sections of this notice. Participants should limit their presentations to approximately 10 minutes, excluding time for questioning by the Commissioners or CPSC staff. To avoid duplicate presentations, groups should designate a spokesperson, and the Commission reserves the right to limit presentation times or impose further restrictions, as necessary.
                </P>
                <SIG>
                    <NAME>Alberta E. Mills,</NAME>
                    <TITLE>Secretary, Consumer Product Safety Commission.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02570 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6355-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">CONSUMER PRODUCT SAFETY COMMISSION</AGENCY>
                <CFR>16 CFR Part 1408</CFR>
                <DEPDOC>[Docket No. CPSC-2019-0020]</DEPDOC>
                <SUBJECT>Safety Standard for Residential Gas Furnaces and Boilers; Notice of Opportunity for Oral Presentations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Consumer Product Safety Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking; opportunity for oral presentation.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Consumer Product Safety Commission (Commission or CPSC) will be providing an opportunity for interested parties to make oral presentations on the notice of proposed rulemaking (NPR) the Commission issued regarding a safety standard for residential gas furnaces and boilers. Presentations will be part of the rulemaking record.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>A hybrid hearing will be held in person at CPSC's headquarters and remotely via webinar and will begin at 10 a.m. Eastern Standard Time (EST) on February 21, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This hearing will be held as a hybrid hearing—in person at CPSC's headquarters and remotely via webinar. For individuals attending in person, the meeting will be held at CPSC's headquarters, located at 4330 East West Highway, 4th Floor—Hearing Room, Bethesda, MD 20814. Individuals who plan to attend the meeting remotely should pre-register for the webinar at 
                        <E T="03">cpsc.webex.com/cpsc/j.php?MTID=m950b2d5a6084894ff5d11b07f635114b</E>
                        . Attendance is free of charge. After registering, you will receive a confirmation email containing information about joining the webinar. In person attendees do not need to register for the hearing. Requests to make oral presentations (in person or remotely) and the text of oral presentations and written comments should be sent by email to: 
                        <E T="03">cpsc-os@cpsc.gov,</E>
                         with the subject line, “Residential Gas Furnaces and Boilers NPR; Oral Presentation.” Requests to make oral presentations—in person or remotely—and the written text of any oral presentations must be received by the Office of the Secretary no later than 5 p.m. EST on February 14, 2024. The Commission will accept written comments as well. These also must be received by the Office of the Secretary no later than 5 p.m. EST on February 14, 2024.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For information about the subject matter of this hearing, contact Ronald A. Jordan, Mechanical Engineering, Consumer Product Safety Commission, 5 Research Place, Rockville, MD 20850; telephone: 301-987-2219; email: 
                        <E T="03">rjordan@cpsc.gov</E>
                        . For information about the procedure to make an oral presentation, contact Alberta E. Mills, Office of the Secretary, Consumer Product Safety Commission, 4330 East-West Highway, Bethesda, MD 20814; telephone: 301-504-7479; 
                        <E T="03">cpsc-os@cpsc.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">
                    I. Background 
                    <E T="51">1</E>
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The Commission voted 4-0 to publish this notice.
                    </P>
                </FTNT>
                <P>
                    On October 25, 2023, the Commission published an NPR in the 
                    <E T="04">Federal Register</E>
                    <E T="03">,</E>
                     proposing to issue a safety standard for residential gas furnaces and boilers under the Consumer Product Safety Act (CPSA; 15 U.S.C. 2051-2089), and seeking written comments. 88 FR 73272. The proposed rule seeks to address the risk of injuries and death associated with residential gas fired central furnaces, boilers, wall furnaces, and floor furnaces (gas furnaces and boilers). To address this risk, the Commission has proposed a rule to detect and prevent dangerous levels of carbon monoxide (CO) production and leakage from residential gas furnaces and boilers.
                </P>
                <P>
                    The NPR is available at: 
                    <E T="03">https://www.federalregister.gov/documents/2023/10/25/2023-23302/safety-standard-for-residential-gas-furnaces-and-boilers,</E>
                     and CPSC staff's briefing package for the NPR is available at: 
                    <E T="03">https://www.cpsc.gov/s3fs-public/Notice-of-Proposed-Rulemaking-Safety-Standard-for-Residential-Gas-Furnaces-and-Boilers-COMBINED-PDFS.pdf?VersionId=7BJ3c6EeDF78nHorx2mCEr94XygwgeQV</E>
                    .
                </P>
                <HD SOURCE="HD1">II. The Public Hearing</HD>
                <P>
                    The Administrative Procedure Act (5 U.S.C. 551-559) and section 9 of the CPSA require the Commission to provide interested parties with an 
                    <PRTPAGE P="8584"/>
                    opportunity to submit “written data, views, or arguments” regarding a proposed rule. 5 U.S.C. 553(c); 15 U.S.C. 2058(d)(2). The NPR invited such written comments. In addition, section 9 of the CPSA requires the Commission to provide interested parties “an opportunity for oral presentation of data, views, or arguments.” 15 U.S.C. 2058(d)(2). The Commission must keep a transcript of such oral presentations. 
                    <E T="03">Id.</E>
                     In accordance with this requirement, the Commission is providing a forum for oral presentations concerning the proposed standard for residential gas furnaces and boilers.
                </P>
                <P>
                    To request the opportunity to make an oral presentation, see the information under the 
                    <E T="02">DATES</E>
                     and 
                    <E T="02">ADDRESSES</E>
                     sections of this notice. Participants should limit their presentations to approximately 10 minutes, excluding time for questions from the Commission or staff. To avoid duplicate presentations, groups should designate a spokesperson, and the Commission reserves the right to limit presentation times or impose further restrictions, as necessary.
                </P>
                <SIG>
                    <NAME>Alberta E. Mills,</NAME>
                    <TITLE>Secretary, Consumer Product Safety Commission.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02563 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6355-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 141</CFR>
                <DEPDOC>[EPA-HQ-OW-2023-0469; FRL-10857-04-OW]</DEPDOC>
                <SUBJECT>Unregulated Contaminant Monitoring Rule; Methods Request and Webinar</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for public comment and notice of a public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Environmental Protection Agency (EPA) is requesting public input on drinking water analytical methods for emerging contaminants in drinking water, particularly those listed on the agency's Fifth Contaminant Candidate List (CCL 5), that might support monitoring under the Unregulated Contaminant Monitoring Rule. This notice describes published drinking water analytical methods and EPA drinking water methods currently in development for the CCL and other emerging contaminants, with an expectation that some of these methods will support the sixth Unregulated Contaminant Monitoring Rule (UCMR 6) and/or other future cycles of the UCMR program.</P>
                    <P>The agency is also announcing a virtual public meeting (via webinar) to discuss potential approaches to developing UCMR 6. The webinar will discuss the following: drinking water analytical methods and contaminants being considered, UCMR 6 sampling design, laboratory approval, and other potential aspects of the monitoring approach. The agenda will include time for brief remarks by participants who pre-register.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        Comments must be received on or before April 8, 2024. 
                        <E T="03">Public meeting:</E>
                         The EPA will host a webinar regarding UCMR 6 development on April 17, 2024 and April 18, 2024. The same material will be presented twice. Please refer to the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section for additional information on the webinar.
                    </P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The agency invites comments on analytical methods for emerging contaminants in drinking water, particularly those listed on CCL 5, to aid in the EPA's consideration of methods to support UCMR monitoring. Comments should refer to Docket ID No. EPA-HQ-OW-2023-0469 and may be submitted by any of the following options:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                          
                        <E T="03">https://www.regulations.gov/</E>
                         (preferred). Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Environmental Protection Agency, EPA Docket Center, Office of Ground Water and Drinking Water Docket, Mail Code 28221T, 1200 Pennsylvania Avenue NW, Washington, DC 20460.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         EPA Docket Center, WJC West Building, Room 3334, 1301 Constitution Avenue NW, Washington, DC 20004. The Docket Center's hours of operations are 8:30 a.m. to 4:30 p.m., Monday through Friday (except Federal Holidays).
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All material submitted must include the Docket ID for this rulemaking. Comments received by the EPA (regardless of how they are submitted) may be posted without change to 
                        <E T="03">https://www.regulations.gov/,</E>
                         including any personal information provided. For detailed instructions on sending comments, see the “Public Participation” heading of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this document.
                    </P>
                    <P>
                        Registration information for the UCMR 6 “pre-proposal” webinar can be found at 
                        <E T="03">https://www.epa.gov/dwucmr/unregulated-contaminant-monitoring-rule-ucmr-meetings-and-materials.</E>
                         The webinars will begin at 11:00 a.m. eastern time and will conclude at 5:00 p.m. eastern time on the scheduled dates. Refer to the “Public Participation” heading of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section below for additional information if you would like to sign up to make remarks during the webinar.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Brenda Bowden, Standards and Risk Management Division, Office of Ground Water and Drinking Water (MS 140), Environmental Protection Agency, 26 West Martin Luther King Drive, Cincinnati, OH 45268; telephone number: (513) 569-7961; or email address: 
                        <E T="03">bowden.brenda@epa.gov;</E>
                         or Will Adams, Standards and Risk Management Division, Office of Ground Water and Drinking Water (MS 140), Environmental Protection Agency, 26 West Martin Luther King Drive, Cincinnati, OH 45268; telephone number: (513) 569-7656; or email address: 
                        <E T="03">adams.william@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Public Participation</FP>
                    <FP SOURCE="FP1-2">A. Written Comments on Drinking Water Analytical Methods for Emerging Contaminants</FP>
                    <FP SOURCE="FP1-2">B. Participation in UCMR 6 Pre-Proposal Webinar</FP>
                    <FP SOURCE="FP-2">II. General Information</FP>
                    <FP SOURCE="FP1-2">A. Does this action apply to me?</FP>
                    <FP SOURCE="FP1-2">B. How does the EPA establish health standards for emerging contaminants in drinking water under the Safe Drinking Water Act?</FP>
                    <FP SOURCE="FP1-2">C. Why is the EPA requesting analytical method information on unregulated contaminants in drinking water?</FP>
                    <FP SOURCE="FP1-2">D. What is the basis for this action?</FP>
                    <FP SOURCE="FP-2">III. Background</FP>
                    <FP SOURCE="FP1-2">A. What is the status of the drinking water analytical methods for contaminants on the CCL 5?</FP>
                    <FP SOURCE="FP1-2">B. What drinking water analytical methods are being developed by the EPA to address contaminants on CCL 5?</FP>
                    <FP SOURCE="FP1-2">1. Draft EPA Method(s) for PFAS.</FP>
                    <FP SOURCE="FP1-2">2. Draft EPA Method 562—Determination of selected pesticides in drinking water by solid phase extraction and liquid chromatography/tandem mass spectrometry (LC/MS/MS).</FP>
                    <FP SOURCE="FP1-2">3. Draft EPA Method Purgeable Organics—Measurement of purgeable organic compounds in water by capillary column gas chromatography/mass spectrometry (GC/MS). This method is expected to support the analysis of drinking water for 1,2,3-trichloropropane (TCP) and other purgeable organic compounds. The target contaminants for this method are shown in Exhibit 7.</FP>
                    <FP SOURCE="FP1-2">4. Draft EPA Method Legionella—Legionella spp. and Legionella pneumophila quantitative polymerase chain reaction (qPCR) detection.</FP>
                    <FP SOURCE="FP1-2">
                        5. Draft EPA Method Mycobacterium—Mycobacterium abscessus culture 
                        <PRTPAGE P="8585"/>
                        recovery with matrix-assisted laser desorption/ionization mass spectrometry (MALDI-MS).
                    </FP>
                    <FP SOURCE="FP1-2">6. Draft EPA Method Mycobacterium qPCR- Mycobacterium avium and Mycobacterium intracellulare quantitative polymerase chain reaction (qPCR) detection.</FP>
                    <FP SOURCE="FP1-2">C. What other drinking water analytical methods are being considered by the EPA to address emerging contaminants?</FP>
                    <FP SOURCE="FP1-2">1. Draft EPA Method EOF—Screening method for the determination of extractable organic fluorine (EOF) in drinking water by anion exchange solid phase extraction and combustion ion chromatography (CIC).</FP>
                    <FP SOURCE="FP1-2">2. Draft EPA Method Microplastics—Analysis of microplastics in drinking water using spectroscopic instrumentation.</FP>
                    <FP SOURCE="FP1-2">D. What information should the public provide when submitting comments about drinking water analytical methods for CCL 5 and other emerging contaminants?</FP>
                    <FP SOURCE="FP-2">IV. References</FP>
                </EXTRACT>
                <HD SOURCE="HD1">Abbreviations and Acronyms</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">µm Micrometer</FP>
                    <FP SOURCE="FP-1">11Cl-PF3OUdS 11-chloroeicosafluoro-3-oxaundecane-1-sulfonic Acid</FP>
                    <FP SOURCE="FP-1">4:2FTS 1H,1H, 2H, 2H-perfluorohexane Sulfonic Acid</FP>
                    <FP SOURCE="FP-1">6:2FTS 1H,1H, 2H, 2H-perfluorooctane Sulfonic Acid</FP>
                    <FP SOURCE="FP-1">8:2FTS 1H,1H, 2H, 2H-perfluorodecane Sulfonic Acid</FP>
                    <FP SOURCE="FP-1">9Cl-PF3ONS 9-chlorohexadecafluoro-3-oxanonane-1-sulfonic Acid</FP>
                    <FP SOURCE="FP-1">ADONA 4,8-dioxa-3H-perfluorononanoic Acid</FP>
                    <FP SOURCE="FP-1">AOF Adsorbable Organic Fluorine</FP>
                    <FP SOURCE="FP-1">ASTM ASTM International</FP>
                    <FP SOURCE="FP-1">BCAA Bromochloroacetic Acid</FP>
                    <FP SOURCE="FP-1">BCIM Bromochloroiodomethane</FP>
                    <FP SOURCE="FP-1">BDCAA Bromodichloroacetic Acid</FP>
                    <FP SOURCE="FP-1">BDCNM Bromodichloronitromethane</FP>
                    <FP SOURCE="FP-1">BDIM Bromodiiodomethane</FP>
                    <FP SOURCE="FP-1">BFB 4-bromofluorobenzene</FP>
                    <FP SOURCE="FP-1">CASRN Chemical Abstracts Service Registry Number</FP>
                    <FP SOURCE="FP-1">CBI Confidential Business Information</FP>
                    <FP SOURCE="FP-1">CCL Contaminant Candidate List</FP>
                    <FP SOURCE="FP-1">CDIM Chlorodiiodomethane</FP>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">CIC Combustion Ion Chromatography</FP>
                    <FP SOURCE="FP-1">Cq Quantification Cycle</FP>
                    <FP SOURCE="FP-1">CWS Community Water System</FP>
                    <FP SOURCE="FP-1">DBAN Dibromoacetonitrile</FP>
                    <FP SOURCE="FP-1">DBCAA Dibromochloroacetic Acid</FP>
                    <FP SOURCE="FP-1">DBCNM Dibromochloronitromethane</FP>
                    <FP SOURCE="FP-1">DBIM Dibromoiodomethane</FP>
                    <FP SOURCE="FP-1">DBP Disinfection Byproduct</FP>
                    <FP SOURCE="FP-1">DCAN Dichloroacetonitrile</FP>
                    <FP SOURCE="FP-1">DCIM Dichloroiodomethane</FP>
                    <FP SOURCE="FP-1">DI Deionized Water</FP>
                    <FP SOURCE="FP-1">DNA Deoxyribonucleic Acid</FP>
                    <FP SOURCE="FP-1">DTXSID Distributed Structure Searchable Toxicity Substance Identifiers</FP>
                    <FP SOURCE="FP-1">EOF Extractable Organic Fluorine</FP>
                    <FP SOURCE="FP-1">EPA U.S. Environmental Protection Agency</FP>
                    <FP SOURCE="FP-1">FEM Forum on Environmental Measurement</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">FTIR Fourier Transform Infrared</FP>
                    <FP SOURCE="FP-1">GC Gas Chromatography</FP>
                    <FP SOURCE="FP-1">GC/MS Gas Chromatography/Mass Spectrometry</FP>
                    <FP SOURCE="FP-1">HFPO-DA Hexafluoropropylene Oxide Dimer Acid</FP>
                    <FP SOURCE="FP-1">ISO or ISO/TS International Organization for Standardization</FP>
                    <FP SOURCE="FP-1">LC-MS/MS or LC/MS/MS Liquid Chromatography/Tandem Mass Spectrometry</FP>
                    <FP SOURCE="FP-1">LDIR Laser Direct Infrared</FP>
                    <FP SOURCE="FP-1">
                        Leg16S 
                        <E T="03">Legionella</E>
                         Species
                    </FP>
                    <FP SOURCE="FP-1">
                        Lp16S 
                        <E T="03">Legionella pneumophila</E>
                    </FP>
                    <FP SOURCE="FP-1">MALDI-MS Matrix-assisted Laser Desorption/Ionization Mass Spectrometry</FP>
                    <FP SOURCE="FP-1">MBC Carbendazim</FP>
                    <FP SOURCE="FP-1">
                        MIP 
                        <E T="03">Legionella pneumophila</E>
                    </FP>
                    <FP SOURCE="FP-1">mL Milliliter</FP>
                    <FP SOURCE="FP-1">mm Millimeter</FP>
                    <FP SOURCE="FP-1">MTBE Methyl Tert-butyl Ether</FP>
                    <FP SOURCE="FP-1">NAICS North American Industry Classification System</FP>
                    <FP SOURCE="FP-1">NCOD National Contaminant Occurrence Database</FP>
                    <FP SOURCE="FP-1">NDBA Nitrosodibutylamine</FP>
                    <FP SOURCE="FP-1">NDEA N-Nitrosodiethylamine</FP>
                    <FP SOURCE="FP-1">NDMA N-Nitrosodimethylamine</FP>
                    <FP SOURCE="FP-1">NDPA N-Nitrosodi-n-propylamine</FP>
                    <FP SOURCE="FP-1">NDPhA N-Nitrosodiphenylamine</FP>
                    <FP SOURCE="FP-1">NEtFOSAA N-ethyl Perfluorooctanesulfonamidoacetic Acid</FP>
                    <FP SOURCE="FP-1">NFDHA Nonafluoro-3,6-dioxaheptanoic Acid</FP>
                    <FP SOURCE="FP-1">ng/L Nanogram per Liter</FP>
                    <FP SOURCE="FP-1">NMeFOSAA N-methyl Perfluorooctanesulfonamidoacetic Acid</FP>
                    <FP SOURCE="FP-1">NPYR Nitrosopyrrolidine</FP>
                    <FP SOURCE="FP-1">NTM Nontuberculous Mycobacteria</FP>
                    <FP SOURCE="FP-1">NTNCWS Non-Transient Non-Community Water System</FP>
                    <FP SOURCE="FP-1">OGWDW Office of Ground Water and Drinking Water</FP>
                    <FP SOURCE="FP-1">PBI Proprietary Business Information</FP>
                    <FP SOURCE="FP-1">PFAS Per- and Polyfluoroalkyl Substances</FP>
                    <FP SOURCE="FP-1">PFBA Perfluorobutanoic Acid</FP>
                    <FP SOURCE="FP-1">PFBS Perfluorobutanesulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFDA Perfluorodecanoic Acid</FP>
                    <FP SOURCE="FP-1">PFDoA Perfluorododecanoic Acid</FP>
                    <FP SOURCE="FP-1">PFEESA Perfluoro(2-ethoxyethane) Sulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFHpA Perfluoroheptanoic Acid</FP>
                    <FP SOURCE="FP-1">PFHpS Perfluoroheptanesulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFHxA Perfluorohexanoic Acid</FP>
                    <FP SOURCE="FP-1">PFHxS Perfluorohexanesulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFMBA Perfluoro-4-methoxybutanoic acid</FP>
                    <FP SOURCE="FP-1">PFMPA Perfluoro-3-methoxypropanoic Acid</FP>
                    <FP SOURCE="FP-1">PFNA Perfluorononanoic Acid</FP>
                    <FP SOURCE="FP-1">PFOA Perfluorooctanoic Acid</FP>
                    <FP SOURCE="FP-1">PFOS Perfluorooctanesulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFPeA Perfluoropentanoic Acid</FP>
                    <FP SOURCE="FP-1">PFPeS Perfluoropentanesulfonic Acid</FP>
                    <FP SOURCE="FP-1">PFTA Perfluorotetradecanoic Acid</FP>
                    <FP SOURCE="FP-1">PFTrDA Perfluorotridecanoic Acid</FP>
                    <FP SOURCE="FP-1">PFUnA Perfluoroundecanoic Acid</FP>
                    <FP SOURCE="FP-1">PTFE Polytetrafluoroethylene</FP>
                    <FP SOURCE="FP-1">PWS Public Water System</FP>
                    <FP SOURCE="FP-1">QC Quality Control</FP>
                    <FP SOURCE="FP-1">qPCR Quantitative Polymerase Chain Reaction</FP>
                    <FP SOURCE="FP-1">SDWA Safe Drinking Water Act</FP>
                    <FP SOURCE="FP-1">SM Standard Methods for the Examination of Water and Wastewater</FP>
                    <FP SOURCE="FP-1">SPE Solid Phase Extraction</FP>
                    <FP SOURCE="FP-1">SRMD Standards and Risk Management Division</FP>
                    <FP SOURCE="FP-1">TBAA Tribromoacetic Acid</FP>
                    <FP SOURCE="FP-1">TCEP Tris(2-chloroethyl) Phosphate</FP>
                    <FP SOURCE="FP-1">TCNM Chloropicrin (trichloronitromethane)</FP>
                    <FP SOURCE="FP-1">TCP Trichloropropane</FP>
                    <FP SOURCE="FP-1">TIM Iodoform (triiodomethane)</FP>
                    <FP SOURCE="FP-1">UCMR Unregulated Contaminant Monitoring Rule</FP>
                    <FP SOURCE="FP-1">VCSB Voluntary Consensus Standards Board</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Public Participation</HD>
                <HD SOURCE="HD2">A. Written Comments on Drinking Water Analytical Methods for Emerging Contaminants</HD>
                <P>
                    Submit your comments on drinking water analytical methods for emerging contaminants, particularly those listed in this 
                    <E T="04">Federal Register</E>
                     notice, identified by Docket ID No. EPA-HQ-OW-2023-0469, at 
                    <E T="03">https://www.regulations.gov</E>
                     (preferred), or using one of the other options identified in the 
                    <E T="02">ADDRESSES</E>
                     section. Once submitted, comments cannot be edited or removed from the docket. The EPA may publish any comment received to its public docket. Do not submit any information to the EPA via 
                    <E T="03">https://www.regulations.gov</E>
                     that you consider to be Confidential Business Information (CBI), Proprietary Business Information (PBI), or other information whose disclosure is restricted by statute. Multimedia submissions (audio, video, etc.) must be accompanied by a written comment. The written comment is considered the official comment and should include discussion of all points you want to make. The EPA will generally not consider comments or comment contents located outside of the primary submission (
                    <E T="03">i.e.,</E>
                     on the web, cloud, or other file sharing system). Please visit 
                    <E T="03">https://www.epa.gov/dockets/commenting-epa-dockets</E>
                     for additional submission methods; the full EPA public comment policy; information about CBI, PBI, or multimedia submissions; and general guidance on making effective comments.
                </P>
                <HD SOURCE="HD2">B. Participation in UCMR 6 Pre-Proposal Webinar</HD>
                <P>
                    All who want to attend the webinar, please refer to the 
                    <E T="02">SUMMARY</E>
                     section for instructions on webinar registration. For those who want to make remarks at the webinar, the EPA is scheduling speakers. To sign up to speak, please use the online registration form available at 
                    <E T="03">https://www.epa.gov/dwucmr/unregulated-contaminant-monitoring-rule-ucmr-meetings-and-materials</E>
                     or contact the EPA's support contractor, Cadmus, at 
                    <E T="03">UCMRWebinar@cadmusgroup.com.</E>
                     The last day to pre-register to speak at the webinar is April 
                    <PRTPAGE P="8586"/>
                    9, 2024. On April 16, (one day prior), the EPA will post an agenda that will identify scheduled speakers at: 
                    <E T="03">https://www.epa.gov/dwucmr/unregulated-contaminant-monitoring-rule-ucmr-meetings-and-materials.</E>
                     If there is additional time for public speakers after scheduling those who pre-registered, EPA will take requests during the webinar via the chat box. The EPA will accommodate requests to speak (via pre-registration and during the webinar) in the order received and as time permits.
                </P>
                <P>
                    The agency's current plan is to provide each speaker with ten minutes. The EPA may adjust this time depending on the number of organizations that register to speak. The agency asks that only one person present on behalf of an organization. The EPA encourages commenters to provide the agency with an advance copy of their remarks by emailing them to 
                    <E T="03">UCMRWebinar@cadmusgroup.com</E>
                    . The EPA may ask and answer clarifying questions during the webinar but will generally not respond to the remarks made by speakers during the webinar.
                </P>
                <P>
                    Please note that any updates to the webinar plan will be posted to 
                    <E T="03">https://www.epa.gov/dwucmr/unregulated-contaminant-monitoring-rule-ucmr-meetings-and-materials</E>
                     and will be emailed to those who register to participate. The EPA does not intend to publish another document in the 
                    <E T="04">Federal Register</E>
                     announcing updates, if any. If you require the services of an interpreter or special accommodations, please identify your needs at least one week in advance as part of your registration.
                </P>
                <HD SOURCE="HD1">II. General Information</HD>
                <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                <P>This notice invites comments on drinking water analytical methods and is directed to those interested in or involved with developing analytical methods for unregulated contaminants in drinking water. It may also be of particular interest to laboratories that conduct chemical or microbiological testing for drinking water contaminants, including testing in support of the UCMR program.</P>
                <P>This notice also announces a webinar to discuss potential approaches to developing UCMR 6. This notice does not impose any requirements.</P>
                <GPOTABLE COLS="3" OPTS="L2,nj,tp0,i1" CDEF="s50,r150,6">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Category</CHED>
                        <CHED H="1">Examples of potentially regulated entities</CHED>
                        <CHED H="1">NAICS *</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">State, local, &amp; Tribal governments</ENT>
                        <ENT>State, local, and Tribal governments that analyze water samples on behalf of PWSs required to conduct such analysis; State, local, and Tribal governments that directly operate Community Water Systems (CWSs) and Non-Transient Non-Community Water Systems (NTNCWSs) required to monitor</ENT>
                        <ENT>924110</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Industry</ENT>
                        <ENT>Private operators of CWSs and NTNCWSs required to monitor</ENT>
                        <ENT>221310</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Municipalities</ENT>
                        <ENT>Municipal operators of CWSs and NTNCWSs required to monitor</ENT>
                        <ENT>924110</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Laboratories</ENT>
                        <ENT>Laboratories conducting analysis</ENT>
                        <ENT>541380</ENT>
                    </ROW>
                    <TNOTE>* NAICS = North American Industry Classification System</TNOTE>
                </GPOTABLE>
                <P>
                    This table is not intended to be exhaustive, but rather provides a guide for readers regarding entities likely to be affected by this action. This table includes the types of entities that the EPA is now aware could potentially be affected by this action. Other types of entities not listed could also be affected. To determine whether your entity is affected by this action, you should carefully examine the applicability criteria found in Title 40 in the 
                    <E T="03">Code of Federal Regulations</E>
                     (CFR) at 40 CFR 141.2 and 141.3, and the applicability criteria found in 40 CFR 141.40(a)(1) and (2). If you have questions regarding the applicability of this action to a particular entity, consult the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section.
                </P>
                <HD SOURCE="HD2">B. How does the EPA establish health standards for emerging contaminants in drinking water under the Safe Drinking Water Act?</HD>
                <P>
                    Under the 1996 amendments to the Safe Drinking Water Act (SDWA), Congress established a multi-step, risk-based approach for determining which contaminants could become subject to drinking water standards. The EPA is required to publish a Contaminant Candidate List (CCL) every five years that identifies contaminants that are not subject to any proposed or promulgated drinking water regulations, are known or anticipated to occur in Public Water Systems (PWSs), and may require future regulation under SDWA. The EPA must also determine whether or not to regulate at least five contaminants from the CCL in a separate process called Regulatory Determinations. Information on these processes can be found at: 
                    <E T="03">https://www.epa.gov/ccl.</E>
                </P>
                <P>
                    Per SDWA, the EPA implements section 1445(a)(2), Monitoring Program for Unregulated Contaminants. The EPA requires that PWSs monitor for a new set of unregulated contaminants every five years to generate occurrence data in support of the agency's CCL and Regulatory Determination processes. The EPA must vary the frequency and schedule for monitoring based on the number of people served, the source water, and the contaminants likely to be found. The data collected through the UCMR program are made available to the public through the National Contaminant Occurrence Database (NCOD) for drinking water. UCMR results can be viewed by the public via NCOD (
                    <E T="03">https://www.epa.gov/sdwa/national-contaminant-occurrence-database-ncod</E>
                    ) or via the UCMR web page at: 
                    <E T="03">https://www.epa.gov/dwucmr.</E>
                </P>
                <HD SOURCE="HD2">C. Why is the EPA requesting analytical method information on unregulated contaminants in drinking water?</HD>
                <P>Analytical methods are essential to gathering occurrence data under the UCMR program. Robust analytical methods with sufficient sensitivity, accuracy, and precision are needed.</P>
                <HD SOURCE="HD2">D. What is the basis for this action?</HD>
                <P>
                    This notice provides the public with the EPA's assessment of published drinking water analytical methods and methods in development for emerging contaminants, particularly those focusing on the CCL 5. The EPA is seeking public comments on method development to reach a broader audience and provide an opportunity to improve public participation. Separate public meetings on method development have not been well attended in the past, and this 
                    <E T="04">Federal Register</E>
                     notice enables those who cannot participate in the meeting to provide input.
                </P>
                <P>
                    This notice also announces webinars in April 2024 that will allow for early engagement in the agency's development of UCMR 6.
                    <PRTPAGE P="8587"/>
                </P>
                <HD SOURCE="HD1">III. Background</HD>
                <HD SOURCE="HD2">A. What is the status of the drinking water analytical methods for contaminants on the CCL 5?</HD>
                <P>
                    Exhibits 1-5 list the contaminants on the final CCL 5 in the 
                    <E T="04">Federal Register</E>
                     published November 14, 2022 (87 FR 68060) (USEPA, 2022b). The current status of drinking water analytical methods from the EPA and voluntary consensus standards bodies (VCSBs) such as, ASTM International (ASTM), Standard Methods (SM), and International Organization for Standardization (ISO), are included in this notice. The ASTM, SM, and ISO methods listed in Exhibits 1-5 may or may not contain the standards and quality control (QC) requirements deemed necessary by the agency and may need to be adapted to support UCMR monitoring. Exhibits 6-10 list methods in development by the EPA for contaminants from CCL 5 that do not currently have drinking water analytical methods. The EPA recognizes that there may be other entities developing drinking water analytical methods and encourages commenters to make the agency aware of them. Please submit comments to the EPA following the process described in section III.D of this notice.
                </P>
                <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s50,12,15,r75">
                    <TTITLE>Exhibit 1—CCL 5 Chemical Contaminants/Groups and Associated Drinking Water Analytical Methods</TTITLE>
                    <BOXHD>
                        <CHED H="1">Chemical name</CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>2</SU>
                        </CHED>
                        <CHED H="1">
                            Drinking water method(s) 
                            <SU>3</SU>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1,2,3-Trichloropropane</ENT>
                        <ENT>96-18-4</ENT>
                        <ENT>DTXSID9021390</ENT>
                        <ENT>In Development, EPA 502.2, EPA 504.1, EPA 524.2, EPA 524.3, EPA 524.4, EPA 551.1, ASTM D5790-18, SM 6200 B, SM 6200 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1,4-Dioxane</ENT>
                        <ENT>123-91-1</ENT>
                        <ENT>DTXSID4020533</ENT>
                        <ENT>EPA 522, EPA 541.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">17-alpha ethynyl estradiol</ENT>
                        <ENT>57-63-6</ENT>
                        <ENT>DTXSID5020576</ENT>
                        <ENT>EPA 539.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2,4-Dinitrophenol</ENT>
                        <ENT>51-28-5</ENT>
                        <ENT>DTXSID0020523</ENT>
                        <ENT>EPA 528.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2-Aminotoluene</ENT>
                        <ENT>95-53-4</ENT>
                        <ENT>DTXSID1026164</ENT>
                        <ENT>EPA 530.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2-Hydroxyatrazine</ENT>
                        <ENT>2163-68-0</ENT>
                        <ENT>DTXSID6037807</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6-Chloro-1,3,5-triazine-2,4-diamine</ENT>
                        <ENT>3397-62-4</ENT>
                        <ENT>DTXSID1037806</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Acephate</ENT>
                        <ENT>30560-19-1</ENT>
                        <ENT>DTXSID8023846</ENT>
                        <ENT>EPA 538.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Acrolein</ENT>
                        <ENT>107-02-8</ENT>
                        <ENT>DTXSID5020023</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">alpha-Hexachlorocyclohexane</ENT>
                        <ENT>319-84-6</ENT>
                        <ENT>DTXSID2020684</ENT>
                        <ENT>EPA 508, EPA 508.1, EPA 525.2, EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Anthraquinone</ENT>
                        <ENT>84-65-1</ENT>
                        <ENT>DTXSID3020095</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bensulide</ENT>
                        <ENT>741-58-2</ENT>
                        <ENT>DTXSID9032329</ENT>
                        <ENT>EPA 540, EPA 543.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bisphenol A</ENT>
                        <ENT>80-05-7</ENT>
                        <ENT>DTXSID7020182</ENT>
                        <ENT>SM 6810 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Boron</ENT>
                        <ENT>7440-42-8</ENT>
                        <ENT>DTXSID3023922</ENT>
                        <ENT>EPA 200.5, EPA 200.7, SM 3120 B, SM 4500-B B, SM 4500-B C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bromoxynil</ENT>
                        <ENT>1689-84-5</ENT>
                        <ENT>DTXSID3022162</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Carbaryl</ENT>
                        <ENT>63-25-2</ENT>
                        <ENT>DTXSID9020247</ENT>
                        <ENT>EPA 531.1, EPA 531.2, ASTM D5315-04, SM 6610 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Carbendazim (MBC)</ENT>
                        <ENT>10605-21-7</ENT>
                        <ENT>DTXSID4024729</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Chlordecone (Kepone)</ENT>
                        <ENT>143-50-0</ENT>
                        <ENT>DTXSID1020770</ENT>
                        <ENT>EPA 527 *, In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Chlorpyrifos</ENT>
                        <ENT>2921-88-2</ENT>
                        <ENT>DTXSID4020458</ENT>
                        <ENT>EPA 525.2, EPA 525.3, EPA 527, EPA 600/R-16/114.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Cobalt</ENT>
                        <ENT>7440-48-4</ENT>
                        <ENT>DTXSID1031040</ENT>
                        <ENT>EPA 200.7, EPA 200.8, EPA 200.9, ASTM D3558-15 A, ASTM D3558-15 B, SM 3111 B, SM 3111 C, SM 3113 B, SM 3120 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Cyanotoxins 
                            <SU>4</SU>
                             
                            <SU>5</SU>
                        </ENT>
                        <ENT>Multiple</ENT>
                        <ENT>Multiple</ENT>
                        <ENT>See Exhibit 2.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Desethylatrazine</ENT>
                        <ENT>6190-65-4</ENT>
                        <ENT>DTXSID5037494</ENT>
                        <ENT>EPA 523, EPA 536.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Desisopropyl atrazine</ENT>
                        <ENT>1007-28-9</ENT>
                        <ENT>DTXSID0037495</ENT>
                        <ENT>EPA 523, EPA 536.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Desvenlafaxine</ENT>
                        <ENT>93413-62-8</ENT>
                        <ENT>DTXSID40869118</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Diazinon</ENT>
                        <ENT>333-41-5</ENT>
                        <ENT>DTXSID9020407</ENT>
                        <ENT>EPA 526.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dicrotophos</ENT>
                        <ENT>141-66-2</ENT>
                        <ENT>DTXSID9023914</ENT>
                        <ENT>EPA 538, EPA 600/R-16/114.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dieldrin</ENT>
                        <ENT>60-57-1</ENT>
                        <ENT>DTXSID9020453</ENT>
                        <ENT>EPA 505, EPA 508, EPA 508.1, EPA 525.2, EPA 525.3, ASTM D5175-91.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dimethoate</ENT>
                        <ENT>60-51-5</ENT>
                        <ENT>DTXSID7020479</ENT>
                        <ENT>EPA 527.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Disinfection byproducts (DBPs) 
                            <SU>4</SU>
                             
                            <SU>6</SU>
                        </ENT>
                        <ENT>Multiple</ENT>
                        <ENT>Multiple</ENT>
                        <ENT>See Exhibit 3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Diuron</ENT>
                        <ENT>330-54-1</ENT>
                        <ENT>DTXSID0020446</ENT>
                        <ENT>EPA 532.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Ethalfluralin</ENT>
                        <ENT>55283-68-6</ENT>
                        <ENT>DTXSID8032386</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Ethoprop</ENT>
                        <ENT>13194-48-4</ENT>
                        <ENT>DTXSID4032611</ENT>
                        <ENT>EPA 507, EPA 525.2, EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fipronil</ENT>
                        <ENT>120068-37-3</ENT>
                        <ENT>DTXSID4034609</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fluconazole.</ENT>
                        <ENT>86386-73-4</ENT>
                        <ENT>DTXSID3020627</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Flufenacet</ENT>
                        <ENT>142459-58-3</ENT>
                        <ENT>DTXSID2032552</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fluometuron</ENT>
                        <ENT>2164-17-2</ENT>
                        <ENT>DTXSID8020628</ENT>
                        <ENT>EPA 532.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Iprodione</ENT>
                        <ENT>36734-19-7</ENT>
                        <ENT>DTXSID3024154</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Lithium</ENT>
                        <ENT>7439-93-2</ENT>
                        <ENT>DTXSID5036761</ENT>
                        <ENT>EPA 200.7, ASTM D1976-20, SM 3111 B, SM 3120 B, SM 3500-Li B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Malathion</ENT>
                        <ENT>121-75-5</ENT>
                        <ENT>DTXSID4020791</ENT>
                        <ENT>EPA 527.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Manganese</ENT>
                        <ENT>7439-96-5</ENT>
                        <ENT>DTXSID2024169</ENT>
                        <ENT>EPA 200.5, EPA 200.7, EPA 200.8, EPA 200.9, SM 3111 B, SM 3111 C, SM 3113 B, SM 3120 B, SM 3500-Mn B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Methomyl</ENT>
                        <ENT>16752-77-5</ENT>
                        <ENT>DTXSID1022267</ENT>
                        <ENT>EPA 531.1, EPA 531.2, EPA 540, ASTM D5315-04, ASTM D7645-23, SM 6610 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Methyl tert-butyl ether (MTBE)</ENT>
                        <ENT>1634-04-4</ENT>
                        <ENT>DTXSID3020833</ENT>
                        <ENT>EPA 524.2, EPA 524.3, EPA 524.4, ASTM D5790-18, SM 6200 B, SM 6200 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Methylmercury</ENT>
                        <ENT>22967-92-6</ENT>
                        <ENT>DTXSID9024198</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Molybdenum</ENT>
                        <ENT>7439-98-7</ENT>
                        <ENT>DTXSID1024207</ENT>
                        <ENT>EPA 200.7, EPA 200.8, SM 3111 D, SM 3113 B, SM 3120 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Nonylphenol 
                            <SU>7</SU>
                        </ENT>
                        <ENT>25154-52-3</ENT>
                        <ENT>DTXSID3021857</ENT>
                        <ENT>EPA 559.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Norflurazon</ENT>
                        <ENT>27314-13-2</ENT>
                        <ENT>DTXSID8024234</ENT>
                        <ENT>EPA 507, EPA 525.2, EPA 525.3, EPA 527.*</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Oxyfluorfen</ENT>
                        <ENT>42874-03-3</ENT>
                        <ENT>DTXSID7024241</ENT>
                        <ENT>EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8588"/>
                        <ENT I="01">
                            Per- and polyfluoroalkyl substances (PFAS) 
                            <SU>4</SU>
                             
                            <SU>8</SU>
                        </ENT>
                        <ENT>Multiple</ENT>
                        <ENT>Multiple</ENT>
                        <ENT>See Exhibit 4.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Permethrin</ENT>
                        <ENT>52645-53-1</ENT>
                        <ENT>DTXSID8022292</ENT>
                        <ENT>EPA 508, EPA 508.1, EPA 525.2, EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Phorate</ENT>
                        <ENT>298-02-2</ENT>
                        <ENT>DTXSID4032459</ENT>
                        <ENT>EPA 525.3, EPA 600/R-16/114.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Phosmet</ENT>
                        <ENT>732-11-6</ENT>
                        <ENT>DTXSID5024261</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Phostebupirim</ENT>
                        <ENT>96182-53-5</ENT>
                        <ENT>DTXSID1032482</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Profenofos</ENT>
                        <ENT>41198-08-7</ENT>
                        <ENT>DTXSID3032464</ENT>
                        <ENT>EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Propachlor</ENT>
                        <ENT>1918-16-7</ENT>
                        <ENT>DTXSID4024274</ENT>
                        <ENT>EPA 508, EPA 508.1, EPA 525.2, EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Propanil</ENT>
                        <ENT>709-98-8</ENT>
                        <ENT>DTXSID8022111</ENT>
                        <ENT>EPA 532.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Propargite</ENT>
                        <ENT>2312-35-8</ENT>
                        <ENT>DTXSID4024276</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Propazine</ENT>
                        <ENT>139-40-2</ENT>
                        <ENT>DTXSID3021196</ENT>
                        <ENT>EPA 507, EPA 523, EPA 525.2, EPA 525.3, EPA 527, EPA 536.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Propoxur</ENT>
                        <ENT>114-26-1</ENT>
                        <ENT>DTXSID7021948</ENT>
                        <ENT>EPA 531.1, EPA 531.2, ASTM D5315-04, SM 6610 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Quinoline</ENT>
                        <ENT>91-22-5</ENT>
                        <ENT>DTXSID1021798</ENT>
                        <ENT>EPA 530, EPA 538.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tebuconazole</ENT>
                        <ENT>107534-96-3</ENT>
                        <ENT>DTXSID9032113</ENT>
                        <ENT>EPA 525.3, EPA 540, EPA 543.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Terbufos</ENT>
                        <ENT>13071-79-9</ENT>
                        <ENT>DTXSID2022254</ENT>
                        <ENT>EPA 526.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Thiamethoxam</ENT>
                        <ENT>153719-23-4</ENT>
                        <ENT>DTXSID2034962</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tri-allate</ENT>
                        <ENT>2303-17-5</ENT>
                        <ENT>DTXSID5024344</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tribufos</ENT>
                        <ENT>78-48-8</ENT>
                        <ENT>DTXSID1024174</ENT>
                        <ENT>EPA 525.3.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tributyl phosphate</ENT>
                        <ENT>126-73-8</ENT>
                        <ENT>DTXSID3021986</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Trimethylbenzene (1,2,4-)</ENT>
                        <ENT>95-63-6</ENT>
                        <ENT>DTXSID6021402</ENT>
                        <ENT>EPA 502.2, EPA 524.2, EPA 524.3, EPA 524.4, ASTM D5790-18, SM 6200 B, SM 6200 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tris(2-chloroethyl) phosphate (TCEP)</ENT>
                        <ENT>115-96-8</ENT>
                        <ENT>DTXSID5021411</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tungsten</ENT>
                        <ENT>7440-33-7</ENT>
                        <ENT>DTXSID8052481</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vanadium</ENT>
                        <ENT>7440-62-2</ENT>
                        <ENT>DTXSID2040282</ENT>
                        <ENT>EPA 200.5, EPA 200.7, EPA 200.8, SM 3111 D, SM 3120 B, SM 3500-V B.</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         Published methods are listed by EPA number or VCSB number. Methods in development by the EPA, or for which research is still needed, are also identified.
                    </TNOTE>
                    <TNOTE>
                        <SU>4</SU>
                         EPA's approach to listing cyanotoxins, DBPs, and PFAS as groups on CCL 5 as opposed to listing them as individual contaminants limits duplication of agency efforts, such as data gathering, analyses and evaluations. Listing these three chemical groups on the CCL 5 does not necessarily mean that EPA will make subsequent regulatory decisions for the entire group.
                    </TNOTE>
                    <TNOTE>
                        <SU>5</SU>
                         As defined in CCL 5, toxins naturally produced and released by some species of cyanobacteria (also known as “blue-green algae”). The group of cyanotoxins includes, but is not limited to: anatoxin-a, cylindrospermopsin, microcystins, and saxitoxin as shown in Exhibit 2.
                    </TNOTE>
                    <TNOTE>
                        <SU>6</SU>
                         This CCL 5 group includes 23 unregulated DBPs as shown in Exhibit 3.
                    </TNOTE>
                    <TNOTE>
                        <SU>7</SU>
                         The CCL 5 lists a general nonylphenol with a CASRN of 25154-52-3. EPA Method 559 analyzes nonylphenol with a CASRN of 84852-15-3 and reports technical nonylphenol, comprised mostly of branched C9-alkyl phenols, and not linear nonylphenol (CASRN 104-40-5) which is a laboratory generated chemical not typically found in the environment.
                    </TNOTE>
                    <TNOTE>
                        <SU>8</SU>
                         The CCL 5 structural definition of per- and polyfluoroalkyl substances (PFAS) includes chemicals that contain at least one of these three structures as shown in Exhibit 4 (except for PFOA and PFOS which are already in the regulatory process):
                    </TNOTE>
                    <TNOTE>1. R-(CF2)-CF(R′)R″, where both the CF2 and CF moieties are saturated carbons, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>2. R-CF2OCF2-R′, where both the CF2 moieties are saturated carbons, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>3. CF3C(CF3)RR′, where all the carbons are saturated, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>* EPA Method 527 indicates these specific contaminants may have potential complications.</TNOTE>
                </GPOTABLE>
                <P>
                    The CCL 5 includes cyanotoxins as a group, including but not limited to the contaminants in Exhibit 2. The EPA recognizes there are other contaminants in this group such as, nodularin-R (which is not a microcystin), as well as, derivatives and congeners of anatoxin-a, cylindrospermopsin, and saxitoxin (
                    <E T="03">e.g.,</E>
                     homoanatoxin-a, deoxy-cylindrospermopsin, and other paralytic shellfish poisons).
                </P>
                <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s75,12,15,r50">
                    <TTITLE>Exhibit 2—Unregulated Cyanotoxins Group on CCL 5 and Associated Drinking Water Analytical Methods</TTITLE>
                    <TDESC>[See Exhibit 1 footnote 4]</TDESC>
                    <BOXHD>
                        <CHED H="1">Chemical name</CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>2</SU>
                        </CHED>
                        <CHED H="1">
                            Drinking water method(s) 
                            <SU>3</SU>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Anatoxin-a</ENT>
                        <ENT>64285-06-9</ENT>
                        <ENT>DTXSID50867064</ENT>
                        <ENT>EPA 545.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Cylindrospermopsin</ENT>
                        <ENT>143545-90-8</ENT>
                        <ENT>DTXSID2031083</ENT>
                        <ENT>EPA 545.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Saxitoxin</ENT>
                        <ENT>35523-89-8</ENT>
                        <ENT>DTXSID3074313</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Microcystins</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Microcystin LA</ENT>
                        <ENT>96180-79-9</ENT>
                        <ENT>DTXSID3031656</ENT>
                        <ENT>EPA 544.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Microcystin LR</ENT>
                        <ENT>101043-37-2</ENT>
                        <ENT>DTXSID3031654</ENT>
                        <ENT>EPA 544.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Microcystin LW</ENT>
                        <ENT>157622-02-1</ENT>
                        <ENT>DTXSID70891285</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Microcystin RR</ENT>
                        <ENT>111755-37-4</ENT>
                        <ENT>DTXSID40880085</ENT>
                        <ENT>EPA 544.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8589"/>
                        <ENT I="01">Microcystin YR</ENT>
                        <ENT>101064-48-6</ENT>
                        <ENT>DTXSID00880086</ENT>
                        <ENT>EPA 544.</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         Published methods are listed by EPA number or VCSB number. Methods in development by the EPA, or for which research is still needed, are also identified.
                    </TNOTE>
                </GPOTABLE>
                <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s75,12,15,r50">
                    <TTITLE>Exhibit 3—Unregulated DBP Group on CCL 5 and Associated Drinking Water Analytical Methods</TTITLE>
                    <TDESC>[See Exhibit 1 footnote 5]</TDESC>
                    <BOXHD>
                        <CHED H="1">Chemical name</CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>2</SU>
                        </CHED>
                        <CHED H="1">
                            Drinking water method(s) 
                            <SU>3</SU>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Haloacetic Acids</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Bromochloroacetic acid (BCAA)</ENT>
                        <ENT>5589-96-8</ENT>
                        <ENT>DTXSID4024642</ENT>
                        <ENT>EPA 552.1, EPA 552.2, EPA 552.3, EPA 557, SM 6251 B.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bromodichloroacetic acid (BDCAA)</ENT>
                        <ENT>71133-14-7</ENT>
                        <ENT>DTXSID4024644</ENT>
                        <ENT>EPA 552.2, EPA 552.3, EPA 557.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dibromochloroacetic acid (DBCAA)</ENT>
                        <ENT>5278-95-5</ENT>
                        <ENT>DTXSID3031151</ENT>
                        <ENT>EPA 552.2, EPA 552.3, EPA 557.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Tribromoacetic acid (TBAA)</ENT>
                        <ENT>75-96-7</ENT>
                        <ENT>DTXSID6021668</ENT>
                        <ENT>EPA 552.2, EPA 552.3, EPA 557.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Haloacetonitriles</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Dichloroacetonitrile (DCAN)</ENT>
                        <ENT>3018-12-0</ENT>
                        <ENT>DTXSID3021562</ENT>
                        <ENT>EPA 551.1.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Dibromoacetonitrile (DBAN)</ENT>
                        <ENT>3252-43-5</ENT>
                        <ENT>DTXSID3024940</ENT>
                        <ENT>EPA 551.1.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Halonitromethanes</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Bromodichloronitromethane (BDCNM)</ENT>
                        <ENT>918-01-4</ENT>
                        <ENT>DTXSID4021509</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Chloropicrin (trichloronitromethane, TCNM)</ENT>
                        <ENT>76-06-2</ENT>
                        <ENT>DTXSID0020315</ENT>
                        <ENT>EPA 551.1.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Dibromochloronitromethane (DBCNM)</ENT>
                        <ENT>1184-89-0</ENT>
                        <ENT>DTXSID00152114</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Iodinated Trihalomethanes</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Bromochloroiodomethane (BCIM)</ENT>
                        <ENT>34970-00-8</ENT>
                        <ENT>DTXSID9021502</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bromodiiodomethane (BDIM)</ENT>
                        <ENT>557-95-9</ENT>
                        <ENT>DTXSID70204235</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Chlorodiiodomethane (CDIM)</ENT>
                        <ENT>638-73-3</ENT>
                        <ENT>DTXSID20213251</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dibromoiodomethane (DBIM)</ENT>
                        <ENT>593-94-2</ENT>
                        <ENT>DTXSID60208040</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dichloroiodomethane (DCIM)</ENT>
                        <ENT>594-04-7</ENT>
                        <ENT>DTXSID7021570</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Iodoform (triiodomethane, TIM)</ENT>
                        <ENT>75-47-8</ENT>
                        <ENT>DTXSID4020743</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Nitrosamines</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Nitrosodibutylamine (NDBA)</ENT>
                        <ENT>924-16-3</ENT>
                        <ENT>DTXSID2021026</ENT>
                        <ENT>EPA 521, SM 6450 B, SM 6450 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-Nitrosodiethylamine (NDEA)</ENT>
                        <ENT>55-18-5</ENT>
                        <ENT>DTXSID2021028</ENT>
                        <ENT>EPA 521, SM 6450 B, SM 6450 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-Nitrosodimethylamine (NDMA)</ENT>
                        <ENT>62-75-9</ENT>
                        <ENT>DTXSID7021029</ENT>
                        <ENT>EPA 521, SM 6450 B, SM 6450 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-Nitrosodi-n-propylamine (NDPA)</ENT>
                        <ENT>621-64-7</ENT>
                        <ENT>DTXSID6021032</ENT>
                        <ENT>EPA 521, SM 6450 B, SM 6450 C.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-Nitrosodiphenylamine (NDPhA)</ENT>
                        <ENT>86-30-6</ENT>
                        <ENT>DTXSID6021030</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Nitrosopyrrolidine (NPYR)</ENT>
                        <ENT>930-55-2</ENT>
                        <ENT>DTXSID8021062</ENT>
                        <ENT>EPA 521, SM 6450 B, SM 6450 C.</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Others</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Chlorate</ENT>
                        <ENT>14866-68-3</ENT>
                        <ENT>DTXSID3073137</ENT>
                        <ENT>EPA 300.1, ASTM D6581-18, SM 4110 D.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Formaldehyde</ENT>
                        <ENT>50-00-0</ENT>
                        <ENT>DTXSID7020637</ENT>
                        <ENT>EPA 554, EPA 556.1, SM 6252 B.*</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         Published methods are listed by EPA number or VCSB number. Methods in development by the EPA, or for which research is still needed, are also identified.
                    </TNOTE>
                    <TNOTE>* SM 6252 B is in the 24th edition of SM titled as proposed.</TNOTE>
                </GPOTABLE>
                <P>
                    The CCL 5 included PFAS as a group which includes thousands of PFAS chemicals per the CCL 5 structural definition (USEPA, 2022b). Exhibit 4 lists the PFAS that EPA has available drinking water analytical methods. The 
                    <PRTPAGE P="8590"/>
                    EPA recognizes that the PFAS in Exhibit 4 only captures a subset of the thousands of PFAS compounds encompassed in the CCL 5 structural definition (USEPA, 2023).
                </P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s75,12,15,xs90">
                    <TTITLE>Exhibit 4—Unregulated PFAS Group With Available Drinking Water Analytical Methods</TTITLE>
                    <TDESC>[See Exhibit 1 footnote 7]</TDESC>
                    <BOXHD>
                        <CHED H="1">
                            Chemical name 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>2</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>3</SU>
                        </CHED>
                        <CHED H="1">
                            Drinking water
                            <LI>
                                method(s) 
                                <SU>4</SU>
                            </LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">11-chloroeicosafluoro-3-oxaundecane-1-sulfonic acid (11Cl-PF3OUdS)</ENT>
                        <ENT>763051-92-9</ENT>
                        <ENT>DTXSID40892507</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9-chlorohexadecafluoro-3-oxanonane-1-sulfonic acid (9Cl-PF3ONS)</ENT>
                        <ENT>756426-58-1</ENT>
                        <ENT>DTXSID80892506</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4,8-dioxa-3H-perfluorononanoic acid (ADONA)</ENT>
                        <ENT>919005-14-4</ENT>
                        <ENT>DTXSID40881350</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Hexafluoropropylene oxide dimer acid (HFPO-DA)</ENT>
                        <ENT>13252-13-6</ENT>
                        <ENT>DTXSID70880215</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Nonafluoro-3,6-dioxaheptanoic acid (NFDHA)</ENT>
                        <ENT>151772-58-6</ENT>
                        <ENT>DTXSID30382063</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorobutanoic acid (PFBA)</ENT>
                        <ENT>375-22-4</ENT>
                        <ENT>DTXSID4059916</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorobutanesulfonic acid (PFBS)</ENT>
                        <ENT>375-73-5</ENT>
                        <ENT>DTXSID5030030</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1H,1H, 2H, 2H-perfluorodecane sulfonic acid (8:2FTS)</ENT>
                        <ENT>39108-34-4</ENT>
                        <ENT>DTXSID00192353</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorodecanoic acid (PFDA)</ENT>
                        <ENT>335-76-2</ENT>
                        <ENT>DTXSID3031860</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorododecanoic acid (PFDoA)</ENT>
                        <ENT>307-55-1</ENT>
                        <ENT>DTXSID8031861</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoro(2-ethoxyethane)sulfonic acid (PFEESA)</ENT>
                        <ENT>113507-82-7</ENT>
                        <ENT>DTXSID50379814</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoroheptanesulfonic acid (PFHpS)</ENT>
                        <ENT>375-92-8</ENT>
                        <ENT>DTXSID8059920</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoroheptanoic acid (PFHpA)</ENT>
                        <ENT>375-85-9</ENT>
                        <ENT>DTXSID1037303</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1H,1H, 2H, 2H-perfluorohexane sulfonic acid (4:2FTS)</ENT>
                        <ENT>757124-72-4</ENT>
                        <ENT>DTXSID30891564</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorohexanesulfonic acid (PFHxS)</ENT>
                        <ENT>355-46-4</ENT>
                        <ENT>DTXSID7040150</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorohexanoic acid (PFHxA)</ENT>
                        <ENT>307-24-4</ENT>
                        <ENT>DTXSID3031862</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoro-3-methoxypropanoic acid (PFMPA)</ENT>
                        <ENT>377-73-1</ENT>
                        <ENT>DTXSID70191136</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoro-4-methoxybutanoic acid (PFMBA)</ENT>
                        <ENT>863090-89-5</ENT>
                        <ENT>DTXSID60500450</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorononanoic acid (PFNA)</ENT>
                        <ENT>375-95-1</ENT>
                        <ENT>DTXSID8031863</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1H,1H, 2H, 2H-perfluorooctane sulfonic acid (6:2FTS)</ENT>
                        <ENT>27619-97-2</ENT>
                        <ENT>DTXSID6067331</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorooctanesulfonic acid (PFOS)</ENT>
                        <ENT>1763-23-1</ENT>
                        <ENT>DTXSID3031864</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorooctanoic acid (PFOA)</ENT>
                        <ENT>335-67-1</ENT>
                        <ENT>DTXSID8031865</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoropentanoic acid (PFPeA)</ENT>
                        <ENT>2706-90-3</ENT>
                        <ENT>DTXSID6062599</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoropentanesulfonic acid (PFPeS)</ENT>
                        <ENT>2706-91-4</ENT>
                        <ENT>DTXSID8062600</ENT>
                        <ENT>EPA 533.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluoroundecanoic acid (PFUnA)</ENT>
                        <ENT>2058-94-8</ENT>
                        <ENT>DTXSID8047553</ENT>
                        <ENT>EPA 533, EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-ethyl perfluorooctanesulfonamidoacetic acid (NEtFOSAA)</ENT>
                        <ENT>2991-50-6</ENT>
                        <ENT>DTXSID5062760</ENT>
                        <ENT>EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">N-methyl perfluorooctanesulfonamidoacetic acid (NMeFOSAA)</ENT>
                        <ENT>2355-31-9</ENT>
                        <ENT>DTXSID10624392</ENT>
                        <ENT>EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorotetradecanoic acid (PFTA)</ENT>
                        <ENT>376-06-7</ENT>
                        <ENT>DTXSID3059921</ENT>
                        <ENT>EPA 537.1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Perfluorotridecanoic acid (PFTrDA)</ENT>
                        <ENT>72629-94-8</ENT>
                        <ENT>DTXSID90868151</ENT>
                        <ENT>EPA 537.1.</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         The CCL 5 structural definition of per- and polyfluoroalkyl substances (PFAS) includes chemicals that contain at least one of these three structures as shown in Exhibit 4 (except for PFOA and PFOS which are already in the regulatory process):
                    </TNOTE>
                    <TNOTE>1. R-(CF2)-CF(R′)R″, where both the CF2 and CF moieties are saturated carbons, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>2. R-CF2OCF2-R′, where both the CF2 moieties are saturated carbons, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>3. CF3C(CF3)RR′, where all the carbons are saturated, and none of the R groups can be hydrogen.</TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                    <TNOTE>
                        <SU>4</SU>
                         Published methods are listed by EPA number or VCSB number. Methods in development by the EPA, or for which research is still needed, are also identified.
                    </TNOTE>
                </GPOTABLE>
                <GPOTABLE COLS="3" OPTS="L2,nj,i1" CDEF="s50,r50,r75">
                    <TTITLE>Exhibit 5—Unregulated Microbial Contaminants on CCL 5 and Associated Drinking Water Analytical Methods</TTITLE>
                    <BOXHD>
                        <CHED H="1">Microorganism</CHED>
                        <CHED H="1">Type of microorganism</CHED>
                        <CHED H="1">
                            Drinking water method(s) 
                            <SU>1</SU>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Adenovirus</ENT>
                        <ENT>Virus</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Caliciviruses</ENT>
                        <ENT>Virus</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Campylobacter jejuni</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Escherichia coli (O157)</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Enterovirus</ENT>
                        <ENT>Virus</ENT>
                        <ENT>EPA 1615.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Helicobacter pylori</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Legionella pneumophila</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>In Development, ASTM D8429-21 *, ISO 11731:2017, ISO/TS 12869:2019.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium abscessus</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium avium</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>In Development.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Naegleria fowleri</E>
                        </ENT>
                        <ENT>Protozoa</ENT>
                        <ENT>SM 9750.**</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Pseudomonas aeruginosa</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>ASTM D5246-19, SM 9213 E, SM 9213 F, SM 9213 G.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Shigella sonnei</E>
                        </ENT>
                        <ENT>Bacteria</ENT>
                        <ENT>Research Needed.</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Published methods are listed by EPA number or VCSB number. Methods in development by the EPA, or for which research is still needed, are also identified.
                    </TNOTE>
                    <TNOTE>* Commonly known as Legiolert® test.</TNOTE>
                    <TNOTE>** SM 9750 is in the 24th edition of SM titled as proposed.</TNOTE>
                </GPOTABLE>
                <PRTPAGE P="8591"/>
                <HD SOURCE="HD2">B. What drinking water analytical methods are being developed by the EPA to address contaminants on CCL 5?</HD>
                <P>1. Draft EPA Method(s) for PFAS.</P>
                <P>
                    The agency continues to conduct research and monitor advances and techniques that may improve our ability to measure PFAS. Preliminary studies have been performed looking at potential method development for PFAS contaminants that are not analyzed in EPA Methods 533 or 537.1. The EPA Methods 533 and 537.1 both address a wide variety of PFAS. These methods were developed focusing on the largest array of PFAS that were commercially available at the time (as certified reference standards) and that could be analyzed while routinely meeting all method-specified quality control criteria (towards the goal of generating accurate and precise results in drinking water sample matrices). EPA is working to expand the method target analyte scope and is soliciting comment and supporting performance data from stakeholders that have conducted similar studies (
                    <E T="03">e.g.,</E>
                     incorporating PFAS with carbon chains less than or equal to three carbons and/or improvements in analytical processing times, such as employing direct injection techniques that could simplify or eliminate the solid-phase extraction step (USEPA, 2019b). EPA anticipates that such improvements would enhance laboratory capability and capacity. EPA invites comments on analytical improvements to Methods 533 and 537.1 or alternative techniques that could prove to be effective at measuring PFAS in drinking water.
                </P>
                <P>2. Draft EPA Method 562—Determination of selected pesticides in drinking water by solid phase extraction and liquid chromatography/tandem mass spectrometry (LC/MS/MS).</P>
                <P>The target contaminants for this method consist of the seven pesticides and three degradates shown in Exhibit 6.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,20,20">
                    <TTITLE>Exhibit 6—Target Contaminants in Draft EPA Method 562</TTITLE>
                    <BOXHD>
                        <CHED H="1">Chemical name</CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>2</SU>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Bromoxynil</ENT>
                        <ENT>1689-84-5</ENT>
                        <ENT>DTXSID3022162.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Carbendazim (MBC)</ENT>
                        <ENT>10605-21-7</ENT>
                        <ENT>DTXSID4024729</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Chlordecone (Kepone)</ENT>
                        <ENT>143-50-0</ENT>
                        <ENT>DTXSID1020770</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Clothianidin</ENT>
                        <ENT>210880-92-5</ENT>
                        <ENT>DTXSID2034465</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fipronil</ENT>
                        <ENT>120068-37-3</ENT>
                        <ENT>DTXSID4034609</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fipronil sulfide</ENT>
                        <ENT>120067-83-6</ENT>
                        <ENT>DTXSID50869644</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fipronil sulfone</ENT>
                        <ENT>120068-36-2</ENT>
                        <ENT>DTXSID6074750</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Flufenacet</ENT>
                        <ENT>142459-58-3</ENT>
                        <ENT>DTXSID2032552</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Iprodione</ENT>
                        <ENT>36734-19-7</ENT>
                        <ENT>DTXSID3024154</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Thiamethoxam</ENT>
                        <ENT>153719-23-4</ENT>
                        <ENT>DTXSID2034962</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                </GPOTABLE>
                <P>The aqueous samples are preserved with ascorbic acid to mitigate free chlorine disinfection and sodium bisulfate to inhibit microbial growth. Extraction efficiency is monitored by adding surrogate compounds to the aqueous samples prior to extraction. Chlordecone and iprodione are known to degrade in the presence of methanol (Bichon et al., 2015; Anisuzzaman et al., 2008); therefore, efforts to avoid the use of methanol were prioritized. Preliminary holding time studies support an aqueous holding time of 14 days and an extract holding time of 28 days. Solid phase extraction (SPE) using divinylbenzene sorbent is used to concentrate the contaminants from the aqueous sample. Additional research may be performed which may allow use of other SPE sorbents provided performance requirements are met. The samples are fully loaded onto the SPE cartridge, followed by a deionized (DI) water bottle wash then an acetone bottle wash to elute the target contaminants. Following elution, nitrogen evaporation is used to reduce the extract. The extract is brought to final volume with an acetone and acetonitrile mixture. The target contaminants are separated using reversed phase liquid chromatography and detected using LC/MS/MS using both positive and negative electrospray ionization. Selected reaction monitoring is used to detect a product ion to maximize selectivity. Instrument variability is corrected using an internal standard.</P>
                <P>The EPA invites comments to support development of this pesticide method. The agency is particularly interested in comments about additional SPE sorbents that provide contaminant recovery meeting the drinking water program's data quality objectives.</P>
                <P>3. Draft EPA Method Purgeable Organics—Measurement of purgeable organic compounds in water by capillary column gas chromatography/mass spectrometry (GC/MS).</P>
                <P>This method is expected to support the analysis of drinking water for 1,2,3-trichloropropane (TCP) and other purgeable organic compounds. The target contaminants for this method are shown in Exhibit 7.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,20,20">
                    <TTITLE>Exhibit 7—Target Contaminants in Draft EPA Method Purgeable Organics</TTITLE>
                    <BOXHD>
                        <CHED H="1">Chemical name</CHED>
                        <CHED H="1">
                            CASRN 
                            <SU>1</SU>
                        </CHED>
                        <CHED H="1">
                            DTXSID 
                            <SU>2</SU>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1,2-dibromo-3-chloropropane</ENT>
                        <ENT>96-12-8</ENT>
                        <ENT>DTXSID3020413</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1,2-dibromoethane</ENT>
                        <ENT>106-93-4</ENT>
                        <ENT>DTXSID3020415</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1,2,3-trichloropropane</ENT>
                        <ENT>96-18-4</ENT>
                        <ENT>DTXSID9021390</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1,2,4-trimethylbenzene</ENT>
                        <ENT>95-63-6</ENT>
                        <ENT>DTXSID6021402</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8592"/>
                        <ENT I="01">Methyl-tert-butyl Ether</ENT>
                        <ENT>1634-04-4</ENT>
                        <ENT>DTXSID3020833</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Chemical Abstracts Service Registry Number (CASRN) is a unique identifier assigned by the Chemical Abstracts Service (a division of the American Chemical Society) to every chemical substance (organic and inorganic compounds, polymers, elements, nuclear particles, etc.) in the open scientific literature. It contains up to 10 digits, separated by hyphens into three parts.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         Distributed Structure Searchable Toxicity Substance Identifiers (DTXSID) is a unique substance identifier used in EPA's CompTox Chemicals database, where a substance can be any single chemical, mixture, or polymer.
                    </TNOTE>
                </GPOTABLE>
                <P>EPA Methods 524.2, 524.3, and 524.4 are used to analyze a variety of organic compounds; however, this method in development is targeting the selected contaminants in Exhibit 9 at quantifiable levels lower than the EPA Methods 524.3 and 524.4 currently achieve (USEPA, 1995g; USEPA, 2009a; USEPA, 2013a). In the draft method, headspace-free samples are collected in amber glass vials with polytetrafluoroethylene (PTFE)-faced septa. Samples are dechlorinated with ascorbic acid and the pH is adjusted with maleic acid. A 5.0 milliliter (mL) or 25-mL aliquot of the sample is transferred to a glass sparging vessel along with appropriate amounts of internal standard and QC compounds. The method contaminants are purged from the water using helium or nitrogen and trapped on a sorbent material. The sample is then heated and backflushed with gas chromatography (GC) carrier gas to transfer the contaminants directly into the gas chromatographic inlet. The inlet is operated in the split mode to achieve the desired desorb flow rates and further reduce water transmission. Contaminants are transferred onto a capillary GC column, which is temperature programmed to optimize the separation of method contaminants. Compounds eluting from the GC are directed into a mass spectrometer for detection and quantitation. The method contaminants are identified by comparing the acquired mass spectra and retention times to reference spectra and retention times. The concentration of each contaminant is calculated using the internal standard technique and response curves obtained via procedural calibration.</P>
                <P>The draft method may differ from EPA Methods 524.2, 524.3, and 524.4 due to removing the requirement for a 4-bromofluorobenzene (BFB) tune as part of the GC/MS optimization and initial calibration, and instead optimizing tuning to maximum ion transmission for the target contaminants of interest. EPA Methods 524.2, 524.3, and 524.4 require a BFB tune, and the draft method will allow optimizing tuning to maximum ion transmission for the target analytes in Exhibit 7. By optimizing conditions specifically for the target contaminants of interest, lower quantitation limits may be achieved. Other changes, such as adjusting the GC split ratio would also be optimized to focus on the specific set of contaminants listed in Exhibit 7.</P>
                <P>The EPA invites comments to support development of this method. The agency is particularly interested in techniques to quantify 1,2,3-TCP at low levels (~5 nanograms per liter (ng/L)).</P>
                <P>
                    4. Draft EPA Method 
                    <E T="03">Legionella</E>
                    —
                    <E T="03">Legionella spp.</E>
                     and 
                    <E T="03">Legionella pneumophila</E>
                     quantitative polymerase chain reaction (qPCR) detection.
                </P>
                <P>The target contaminants for this method are shown in Exhibit 8.</P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s200,xs100">
                    <TTITLE>Exhibit 8—Target Contaminants in Draft EPA Method Legionella</TTITLE>
                    <BOXHD>
                        <CHED H="1">Microorganism</CHED>
                        <CHED H="1">Type of microorganism</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Legionella</E>
                             species (Leg16S)
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Legionella pneumophila</E>
                             (MIP)
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Legionella pneumophila</E>
                             (Lp16S)
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    For this method in development, one assay under consideration will detect all 
                    <E T="03">Legionella</E>
                     species (there are ~53 recognized species). There are two other assays under consideration for 
                    <E T="03">Legionella pneumophila</E>
                     detection. For this method, a one-liter sample is collected in a high-density polypropylene bottle containing sodium thiosulfate for dechlorination. The sample is vacuumed filtered through a 0.45 micrometer (µm) polycarbonate membrane. The captured microbial deoxyribonucleic acid (DNA) is extracted from the membrane. The extracted DNA is analyzed using three qPCR assays utilizing a qPCR instrument.
                </P>
                <P>This method will detect and quantify the targeted microbe of interest. The method identifies the target bacteria using primer-probe specific to the microbe of interest, and the resulting qPCR gene product (DNA sequence) molecular weight is checked. The instrument will generate an amplification curve if the targeted bacteria is present in a sample. As the curve passes the 0.4 threshold, a quantification cycle (Cq) value is determined. The targeted bacteria DNA (Cq value) is then quantified using a standard curve generated from genomic DNA. The method contains other QC samples, including, positive controls such as, the standard curve and negative controls, such as, internal controls, method blanks, extraction blanks, and non-template controls.</P>
                <P>
                    The EPA invites comments to support the development of a 
                    <E T="03">Legionella spp.</E>
                     and 
                    <E T="03">Legionella pneumophila</E>
                     method. The agency is specifically interested in information on environmental laboratory capabilities to perform this method.
                </P>
                <P>
                    5. Draft EPA Method 
                    <E T="03">Mycobacterium—Mycobacterium abscessus</E>
                     culture recovery with matrix-assisted laser desorption/ionization mass spectrometry (MALDI-MS).
                </P>
                <P>
                    The target contaminants for this method are shown in Exhibit 9.
                    <PRTPAGE P="8593"/>
                </P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s200,xs100">
                    <TTITLE>Exhibit 9—Target Contaminants in Draft EPA Method Mycobacterium</TTITLE>
                    <BOXHD>
                        <CHED H="1">Microorganism</CHED>
                        <CHED H="1">Type of microorganism</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium abscessus</E>
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium mucogenicum</E>
                             (potentially)
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>This method is in early development. A one-liter sample is collected in a high-density polypropylene bottle containing sodium thiosulfate for dechlorination. The sample is decontaminated for 30 minutes with 0.4% cetylpyridinium chloride solution. Then, 500 mL of the decontaminated sample is vacuumed filtered through a 0.45 mm black, mixed cellulose membrane. The membrane with the captured bacteria is laid on top of Middlebrook 7H11 agar plate. The plate is incubated at 37 °C for 7 days. The resulting colonies are chosen for matrix-assisted laser desorption/ionization mass spectrometry (MALDI-MS) identification.</P>
                <P>The EPA invites comments to support development of this method. The agency is particularly interested in the following: (1) suggestions for preservation chemical to use; (2) input on detection limits using MALDI-MS; (3) input on the sample volume needed; and (4) feedback regarding any experience with this technique.</P>
                <P>
                    6. Draft EPA Method 
                    <E T="03">Mycobacterium</E>
                     qPCR—
                    <E T="03">Mycobacterium avium</E>
                     and 
                    <E T="03">Mycobacterium intracellulare</E>
                     quantitative polymerase chain reaction (qPCR) detection.
                </P>
                <P>The target contaminants for this method are shown in Exhibit 10.</P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s200,xs100">
                    <TTITLE>Exhibit 10—Target Contaminants in Draft EPA Method Mycobacterium QPCR</TTITLE>
                    <BOXHD>
                        <CHED H="1">Microorganism</CHED>
                        <CHED H="1">Type of microorganism</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium avium</E>
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            <E T="03">Mycobacterium intracellulare</E>
                        </ENT>
                        <ENT>Bacteria.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    This method can distinguish between 
                    <E T="03">Mycobacterium avium</E>
                     and 
                    <E T="03">Mycobacterium intracellulare</E>
                     species. For this method, a one-liter sample is collected in a high-density polypropylene bottle containing sodium thiosulfate for dechlorination. The sample is vacuum-filtered through a 0.45 µm polycarbonate membrane. The captured microbial DNA is extracted from the membrane. The extracted DNA is analyzed using two qPCR assays utilizing a qPCR instrument.
                </P>
                <P>This method will detect and quantify the targeted microbe of interest. The method identifies the target bacteria using primer-probe specific to the microbe of interest, and the resulting qPCR gene product (DNA sequence) molecular weight is checked. The instrument will generate an amplification curve if the targeted bacteria is present in a sample. As the curve passes the 0.4 threshold, a Cq value is determined. The targeted bacteria DNA (Cq value) is then quantified using a standard curve generated from genomic DNA. The method contains other QC samples, including positive controls such as the standard curve, and negative controls such as internal controls, method blanks, extraction blanks, and non-template controls. This method requires the collection of a 200 mL water sample.</P>
                <P>The EPA invites comments to support development of this method. The agency is particularly interested in information on environmental laboratory capabilities to perform this method.</P>
                <HD SOURCE="HD2">C. What other drinking water analytical methods are being considered by the EPA to address emerging contaminants?</HD>
                <P>1. Draft EPA Method EOF—Screening method for the determination of extractable organic fluorine (EOF) in drinking water by anion exchange solid phase extraction and combustion ion chromatography (CIC).</P>
                <P>The target contaminant for this method is Extractable Organic Fluorine (EOF). Targeted PFAS drinking water methods currently only capture a small subset of the many PFAS known to exist. “Aggregate” methods (sometimes referred to as a “total PFAS” method) are designed to capture a larger portion of the PFAS than targeted methods are able to detect. The subject technique seeks to estimate the concentration of EOF in drinking water. It captures organofluorine compounds from PFAS and non-PFAS fluorinated substances that are retained using weak anion exchange SPE. The method has potential application for screening, recognizing that it will not measure fluorinated compounds individually, but as an aggregate sum of the fluorinated compounds captured on the sorbent. Notably, non-PFAS fluorinated compounds may also be accounted for in the reported value along with residual inorganic fluoride that is added to drinking water to prevent tooth decay.</P>
                <P>For this EOF method in development by the EPA, the preservation scheme follows EPA Method 533, with the aqueous samples preserved with ammonium acetate to sequester free chlorine to form chloramine. Additionally, the EOF method follows the EPA Method 533 holding time scheme set at 28 days.</P>
                <P>The drinking water sample is concentrated using weak anion-exchange SPE. After passing the sample through the SPE cartridge, preserved reagent water is pulled through the cartridge, then aqueous ammonium hydroxide is used to wash the SPE cartridge to remove inorganic fluoride. A solution of ammonium hydroxide in methanol is used to elute the adsorbed compounds. The extract is evaporated to dryness and reconstituted in a methanol and water mixture. The entire extract is transferred to a ceramic boat and combusted at high temperature in the furnace of a combustion ion chromatography (CIC) instrument to break the carbon-fluorine bond. The released fluorine is absorbed in a water solution to form the fluoride ion. A portion of the fluoride solution is separated by ion chromatography using a potassium hydroxide-based eluent. External calibration is used to establish the retention time for fluoride and report the extractable organic fluorine as fluoride. The agency notes that aggregate techniques considered to-date do not have the same sensitivity as targeted techniques. The quantitation capabilities of the EOF technique, and the suitability of the technique for drinking water monitoring, continue to be evaluated.</P>
                <P>
                    The agency considered other aggregate methods, including an 
                    <PRTPAGE P="8594"/>
                    adsorbable organic fluorine (AOF) procedure, such as draft EPA Method 1621 (USEPA, 2022a). In the AOF method, larger samples achieve better sensitivity. The agency notes that draft EPA Method 1621 does not retain short carbon PFAS within the data quality objective limits of 70-130%. In addition, draft EPA Method 1621 does not permit rinsing of the sample container, meaning hydrophobic PFAS may be lost to adsorption on the sample container. A method wash step removes inorganic fluoride up to 95%, but a trace amount of inorganic fluoride may remain because of the weak anion exchange sorbent.
                </P>
                <P>The EPA invites comments to support development and consideration of aggregate PFAS measurement. The agency is particularly interested in the following: (1) techniques to extract or adsorb ultra short chain PFAS; (2) alternative ways to remove inorganic fluoride from aqueous drinking water samples prior to or during the extraction or adsorption for organic fluoride; (3) techniques to capture anionic, neutral and cationic PFAS in a single solid phase extraction procedure; and (4) techniques to improve the selectivity of the extraction process to reduce or eliminate retention of non-PFAS fluorinated compounds.</P>
                <P>2. Draft EPA Method Microplastics—Analysis of microplastics in drinking water using spectroscopic instrumentation.</P>
                <P>
                    The target contaminant for this method is “microplastics.” Common spectroscopic libraries contain spectra for thousands of different polymers that can all be identified using these instruments. For this discussion, EPA's water research definition of microplastics is particles ranging in size from 5 millimeters (mm) to 1 mm at 
                    <E T="03">https://www.epa.gov/water-research/microplastics-research.</E>
                </P>
                <P>The agency is in the early stages of developing a microplastics method and is gathering information about analytical approaches. The agency recognizes that voluntary consensus standards bodies (VCSBs) methods ASTM D8332-20 and ASTM D8333-20 are available. This section summarizes the currently available research. In developing the final method approach, the agency will seek to incorporate the latest advancements in microplastic research and analytical methodologies.</P>
                <P>There are a variety of spectroscopic techniques that can be utilized for microplastic analysis, including fourier transform infrared (FTIR) spectroscopy, laser direct infrared (LDIR) spectroscopy, and Raman spectroscopy. The analytical instruments associated with these techniques have more similarities than differences and all provide similar information to characterize microplastics, including size, shape, and polymer type of individual microplastics.</P>
                <P>For all of the spectroscopy techniques examined by the agency, samples are stored at 4 degrees Celsius (Wong and Coffin, 2022) or have a maximum of one freeze and thaw cycle (ITRC, 2023). Depending on the requirements and capabilities of the analytical instrument, a variety of instrument filter types with different coatings and pore sizes have been used to collect microplastics from aqueous samples. For example, the LDIR imaging system uses gold-coated filters that are infrared-reflective. The California State Water Resources Control Board does not recommend density separation or digestion for drinking water samples (Wong and Coffin, 2022).</P>
                <P>Spectroscopic methods only quantify the number of particles, not a mass of polymer, and can identify even a single particle on a filter, so the measurement capability is only related to the size of the particle. Many infrared and Raman-based instruments can identify particles with a minimum diameter of 20 microns and 1-micron, respectively. However, the minimum size for reliable identification on the widest range of instrument models should be considered as 50 microns for infrared-based instruments and 20 microns for Raman-based instruments. (Wong and Coffin, 2022).</P>
                <P>
                    The EPA invites comments to support the development of a microplastics method. The agency is specifically interested in comments that will help identify the changes to microplastics that happen as a result of reactions to environmental exposures (
                    <E T="03">i.e.,</E>
                     sunlight, water, and temperature) and how these changes can affect reliable polymer identification.
                </P>
                <HD SOURCE="HD2">D. What information should the public provide when submitting comments about drinking water analytical methods for CCL 5 and other emerging contaminants?</HD>
                <P>The EPA welcomes comments from the public regarding analytical methods for measuring emerging contaminants in drinking water. This includes methods already published by the agency or others, those under development by the agency or others, and those that should be considered for future development. The agency is particularly interested in methods that may be used to monitor drinking water for the contaminants published on final the CCL 5 (87 FR 68060, November 14, 2022 (USEPA, 2022b)). The agency encourages commenters to include their name, affiliation, phone number, mailing address, and email address. However, this information is not required, and comments can be submitted anonymously. When addressing non-EPA or voluntary consensus standards bodies (VCSBs) methods, comments should address the following, as applicable:</P>
                <P>1. Specify the method name and describe, at least generally, the instrumentation upon which it relies.</P>
                <P>
                    2. Specify the status of the method (
                    <E T="03">e.g.,</E>
                     fully-developed, nearing completion, early development).
                </P>
                <P>
                    3. Specify the emerging contaminant(s), particularly the CCL contaminants, that can be analyzed with the drinking water analytical method. CCL 5 contaminants are listed in Exhibits 1-5 of this notice and at 
                    <E T="03">https://www.federalregister.gov/documents/2022/11/14/2022-23963/drinking-water-contaminant-candidate-list-5-final.</E>
                </P>
                <P>
                    4. Specify method performance information, such as sensitivity, selectivity, accuracy, and precision attainable for the contaminant(s). Describe the degree to which the method performance has been validated; the latter is important for any method being considered by the EPA for UCMR or other purposes. Guidelines for analytical method validation are described by the EPA Forum on Environmental Measurement (FEM) in documents available through the FEM website (USEPA, 2016b, c) at 
                    <E T="03">https://www.epa.gov/measurements-modeling/method-validation-and-peer-review-policies-and-guidelines.</E>
                </P>
                <P>5. To the extent possible, specify the cost, availability, and your laboratory's capacity to run the method commercially.</P>
                <P>6. Provide complete citations for referenced analytical methods, including author(s), title, journal (or other publication), and date.</P>
                <P>7. Provide contact information for the principal investigator, when available.</P>
                <HD SOURCE="HD1">IV. References</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        (i) Anisuzzaman, A., Storehalder, T., Williams, D., Ogg, N., Kilbourne, T., John Samuel, J., &amp; Cottrell, C. 2008. Effect of Alcohols on the Stability of Iprodione in Solution. 
                        <E T="03">Journal of Agricultural and Food Chemiemergingstry,</E>
                         56 (2), 502-506. DOI: 10.1021/jf0720483.
                    </FP>
                    <FP SOURCE="FP-2">
                        (ii) ASTM. 2015. ASTM D3558-15—
                        <E T="03">Standard Test Methods for Cobalt in Water.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved February 1, 2015. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (iii) ASTM. 2017a. ASTM D5175-91—
                        <E T="03">
                            Standard Test Method for Organohalide 
                            <PRTPAGE P="8595"/>
                            Pesticides and Polychlorinated Biphenyls in Water by Microextraction and Gas Chromatography.
                        </E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved December 15, 2017. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (iv) ASTM. 2017b. ASTM D5315-04—
                        <E T="03">Standard Test Method for Determination of N-Methyl-Carbamoyloximes and N-Methylcarbamates in Water by Direct Aqueous Injection HPLC with Post-Column Derivatization.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved December 15, 2017. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (v) ASTM. 2018a. ASTM D6581-18—
                        <E T="03">Standard Test Methods for Bromate, Bromide, Chlorate, and Chlorite in Drinking Water by Suppressed Ion Chromatography.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved May 1, 2018. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (vi) ASTM. 2018b. ASTM D5790-18—
                        <E T="03">Standard Test Method for Measurement of Purgeable Organic Compounds in Water by Capillary Column Gas Chromatography/Mass Spectrometry.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved December 15, 2018. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (vii) ASTM. 2019. ASTM D5246-19—
                        <E T="03">Standard Test Method for Isolation and Enumeration of Pseudomonas aeruginosa from Water.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved December 1, 2019. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (viii) ASTM. 2020a. ASTM D1976-20—
                        <E T="03">Standard Test Method for Elements in Water by Inductively Coupled Plasma Atomic Emission Spectroscopy.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved May 1, 2020. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (ix) ASTM. 2020b. ASTM D8332-20— 
                        <E T="03">Standard Practice for Collection of Water Samples with High, Medium, or Low Suspended Solids for Identification and Quantification of Microplastic Particles and Fibers.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved July 15, 2020. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (x) ASTM. 2020c. ASTM D8333-20— 
                        <E T="03">Standard Practice for Collection of Water Samples with High, Medium, or Low Suspended Solids for Identification and Quantification of Microplastic Particles and Fibers Using Ramen Spectroscopy, IR Spectroscopy, or Pyrolysis-GC/MS.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved July 15, 2020. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (xi) ASTM. 2021. ASTM D8429-21—
                        <E T="03">Standard Test Method for Legionella pneumophila in Water Samples Using Legiolert.</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved 2021. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (xii) ASTM. 2023. ASTM D7645-23—
                        <E T="03">Standard Test Method for Determination of Aldicarb, Aldicarb Sulfone, Aldicarb Sulfoxide, Carbofuran, Methomyl, Oxamyl, and Thiofanox in Water by Liquid Chromatography/Tandem Mass Spectrometry (LC/MS/MS).</E>
                         ASTM, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Approved April 15, 2023. Available for purchase at 
                        <E T="03">astm.org</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        (xiii) Bichon, E., Guiffard, I., Vénisseau, A., Marchand, P., Antignac, J.P., &amp; Le Bizec, B. 2015. Ultra-trace quantification method for chlordecone in human fluids and tissues. 
                        <E T="03">Journal of Chromatography A,</E>
                         1408, 169-177. 
                        <E T="03">DOI.org/10.1016/j.chroma.2015.07.013.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xiv) ISO Online. 2017. 11731:2017—Water Quality—Enumeration of 
                        <E T="03">Legionella. ISO Standards.</E>
                         Available for purchase at 
                        <E T="03">https://www.iso.org/standards.html.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xv) ISO Online. 2019. 12869:2019—Water quality—Detection and quantification of 
                        <E T="03">Legionella</E>
                         spp. and/or 
                        <E T="03">Legionella pneumophila</E>
                         by concentration and genic amplification by quantitative polymerase chain reaction (qPCR). ISO Standards. Available for purchase at 
                        <E T="03">https://www.iso.org/standards.html.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xvi) Interstate Technology Regulatory Council (ITRC). 2023. 
                        <E T="03">Microplastics Outreach Toolkit—Sampling and Analysis.</E>
                         February 2023. Available at 
                        <E T="03">https://mp-1.itrcweb.org/sampling-and-analysis/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xvii) SM Online. 1997a. 3500-V—Vanadium (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xviii) SM Online. 1997b. 6200—Volatile Organic Compounds Method (Editorial Revisions, 2011 and 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xix) SM Online. 1999a. 3111—Metals by Flame Atomic Absorption Spectrometry Method (Editorial Revisions, 2019). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xx) SM Online. 1999b. 3120—Metals by Plasma Emission Spectroscopy Method (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxi) SM Online. 1999c. 3500-Mn—Manganese (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxii) SM Online. 2000a. 4110—Determination of Anions by Ion Chromatography Method (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxiii) SM Online. 2000b. 4500-B—Boron (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxiv) SM Online. 2004a. 3500-Li—Lithium (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxv) SM Online. 2004b. 6610—Carbamate Pesticides Method (Editorial Revisions, 2021). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxvi) SM Online. 2005. 6252—Disinfection Byproducts: Aldehydes Method (Proposed) (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxvii) SM Online. 2007a. 6251—Disinfection Byproducts: Haloacetic Acids and Trichlorophenol Method (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxviii) SM Online. 2007b. 6450—Nitrosamines Method (Editorial Revisions, 2021). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxix) SM Online. 2007c. 9213—Recreational Waters (Editorial Revisions, 2022). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxx) SM Online. 2010. 3113—Metals by Electrothermal Atomic Absorption Spectrometry Method (Editorial Revisions, 2020). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxi) SM Online. 2013. 6810—Pharmaceuticals and Personal Care Products Method (Editorial Revisions, 2021). 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxii) SM Online. 2021. 9750—Detection of 
                        <E T="03">Naegleria fowleri</E>
                         in Water. 
                        <E T="03">Standard Methods Online.</E>
                         Available for purchase at 
                        <E T="03">http://www.standardmethods.org.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxiii) USEPA. 1992a. 
                        <E T="03">Method 552.1—Determination of Haloacetic Acids and Dalapon in Drinking Water by Ion-Exchange Liquid-Solid Extraction and Gas Chromatography with an Electron Capture Detector.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. August 1992. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4784/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxiv) USEPA. 1992b. 
                        <E T="03">Method 554—Determination of Carbonyl Compounds in Drinking Water by Dinitrophenylhydrazine Derivatization and High Performance Liquid Chromatography.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. August 1992. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/12611/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxv) USEPA. 1994a. 
                        <E T="03">Method 200.7—Determination of Metals and Trace Elements in Water and Wastes by Inductively Coupled Plasma-Atomic Emission Spectrometry.</E>
                         Revision 4.4. Office of Research and Development, Cincinnati, OH. 1994. Available at 
                        <E T="03">https://www.epa.gov/esam/method-2007-determination-metals-and-trace-elements-water-and-wastes-inductively-coupled-plasma.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxvi) USEPA. 1994b. 
                        <E T="03">Method 200.8—Determination Trace Elements in Waters and Wastes by Inductively Coupled Plasma-Mass Spectrometry.</E>
                         Revision 5.4. Office of Research and Development, Cincinnati, OH. 1994. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-200.8.pdf.</E>
                        <PRTPAGE P="8596"/>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxvii) USEPA. 1994c. 
                        <E T="03">Method 200.9—Determination of Trace Elements by Stabilized Temperature Graphic Furnace Atomic Absorption.</E>
                         Revision 2.2. Office of Research and Development, Cincinnati, OH. 1994 Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-08/documents/method_200-9_rev_2-2_1994.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxviii) USEPA. 1995a. 
                        <E T="03">Method 502.2—Volatile Organic Compounds in Water by Purge and Trap Capillary Column Gas Chromatography with Photoionization and Electrolytic Conductivity Detectors in Series.</E>
                         Revision 2.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4827/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xxxix) USEPA. 1995b. 
                        <E T="03">Method 504.1—1,2-Dibromoethane (EDB), 1,2-Dibromo-3-Chloro-Propane (DBCP), and 1,2,3-Trichloropropane (123TCP) in Water by Microextraction and Gas Chromatography.</E>
                         Revision 1.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4825/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xl) USEPA. 1995c. 
                        <E T="03">Method 505—Analysis of Organohalide Pesticides and Commercial Polychlorinated Biphenyl (PCB) Products in Water by Microextraction and Gas Chromatography.</E>
                         Revision 2.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4799/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xli) USEPA. 1995d. 
                        <E T="03">Method 507—Determination of Nitrogen and Phosphorus Containing Pesticides in Water by Gas Chromatography with a Nitrogen-Phosphorus Detector.</E>
                         Revision 2.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4801/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlii) USEPA. 1995e. 
                        <E T="03">Method 508—Determination of Chlorinated Pesticides in Water by Gas Chromatography with an Electron Capture Detector.</E>
                         Revision 3.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4826/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xliii) USEPA. 1995f. 
                        <E T="03">Method 508.1—Determination of Chlorinated Pesticides, Herbicides, and Organohalides by Liquid-Solid Extraction and Electron Capture Gas Chromatography.</E>
                         Revision 2.0. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4802/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xliv) USEPA. 1995g. 
                        <E T="03">Method 524.2—Measurement of Purgeable Organic Compounds in Water by Capillary Column Gas Chromatography/Mass Spectrometry.</E>
                         Revision 4.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-524.2.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlv) USEPA. 1995h. 
                        <E T="03">Method 525.2—Determination of Organic Compounds in Drinking Water by Liquid-Solid Extraction and Capillary Column Gas Chromatography/Mass Spectrometry.</E>
                         Revision 2.0. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-525.2.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlvi) USEPA. 1995i. 
                        <E T="03">Method 531.1—Measurement of N-Methylcarbamoyloximes and N-Methylcarbamates in Water by Direct Aqueous Injection HPLC with Post Column Derivatization.</E>
                         Revision 3.1. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4805/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlvii) USEPA. 1995j. 
                        <E T="03">Method 551.1—Determination of Chlorination Disinfection Byproducts, Chlorinated Solvents, and Halogenated Pesticides/Herbicides in Drinking Water by Liquid-Liquid Extraction and Gas Chromatography with Electron-Capture Detection.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-551.1.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlviii) USEPA. 1995k. 
                        <E T="03">Method 552.2—Determination of Haloacetic Acids and Dalapon in Drinking Water by Liquid-Liquid Extraction, Derivatization and Gas Chromatography with Electron Capture Detection.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. 1995. Available at 
                        <E T="03">https://www.nemi.gov/methods/method_summary/4787/.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (xlix) USEPA. 1997. 
                        <E T="03">Method 300.1—Determination of Inorganic Anions in Drinking Water by Ion Chromatography.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. 1997. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-300.1.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (l) USEPA. 1999. 
                        <E T="03">Method 556.1—Determination of Carbonyl Compounds in Drinking Water by Fast Gas Chromatography.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. September 1999. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (li) USEPA. 2000a. 
                        <E T="03">Method 526—Determination of Selected Semivolatile Organic Compounds in Drinking Water by Solid Phase Extraction and Capillary Column Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. June 2000. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lii) USEPA. 2000b. 
                        <E T="03">Method 528—Determination of Phenols in Drinking Water by Solid Phase Extraction and Capillary Column Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. April 2000. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (liii) USEPA. 2000c. 
                        <E T="03">Method 532—Determination of Phenylurea Compounds in Drinking Water by Solid Phase Extraction and High Performance Liquid Chromatography with UV Detection.</E>
                         Revision 1.0. Office of Research and Development, Cincinnati, OH. June 2000. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (liv) USEPA. 2001. 
                        <E T="03">Method 531.2—Measurement of N-Methylcarbamoyloximes and N-Methylcarbamates in Water by Direct Aqueous Injection HPLC with Postcolumn Derivatization.</E>
                         Revision 1.0. EPA 815-B-01-002. Office of Ground Water and Drinking Water, Cincinnati, OH. September 2001. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-06/documents/epa-531.2.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lv) USEPA. 2003a. 
                        <E T="03">Method 552.3—Determination of Haloacetic Acids and Dalapon in Drinking Water by Liquid-Liquid Microextraction, Derivatization, and Gas Chromatography with Electron Capture Detection.</E>
                         Revision 1.0. EPA 815-B-03-002. Office of Ground Water and Drinking Water, Cincinnati, OH. July 2003. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/901V0400.PDF?Dockey=901V0400.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lvi) USEPA. 2003b. 
                        <E T="03">Method 200.5—Determination of Trace Elements in Drinking Water by Axially Viewed Inductively Coupled Plasma-Atomic Emission Spectrometry.</E>
                         Revision 4.2. EPA 600-R-06-115. Office of Research and Development, Cincinnati, OH. October 2003. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2015-08/documents/method_200-5_rev_4-2_2003.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lvii) USEPA. 2004. 
                        <E T="03">Method 521—Determination of Nitrosamines in Drinking Water by Solid Phase Extraction and Capillary Column Gas Chromatography with Large Volume Injection and Chemical Ionization Tandem Mass Spectrometry (MS/MS).</E>
                         Version 1.0. EPA 600-R-05-054. Office of Research and Development, Cincinnati, OH. September 2004. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lviii) USEPA. 2005. 
                        <E T="03">Method 527—Determination of Selected Pesticides and Flame Retardants in Drinking Water by Solid Phase Extraction and Capillary Column Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Revision 1.0. EPA 815-R-05-005. Office of Ground Water and Drinking Water, Cincinnati, OH. April 2005. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lix) USEPA. 2007. 
                        <E T="03">Method 536—Determination of Triazine Pesticides and their Degradates in Drinking Water by Liquid Chromatography Electrospray Ionization Tandem Mass Spectrometry (LC/ESI-MS/MS).</E>
                         Version 1.0. EPA 815-B-07-002. Office of Ground Water and Drinking Water, Cincinnati, OH. October 2007. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P1005E35.PDF?Dockey=P1005E35.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lx) USEPA. 2008. 
                        <E T="03">
                            Method 522—Determination of 1,4-Dioxane in Drinking Water by Solid Phase 
                            <PRTPAGE P="8597"/>
                            Extraction (SPE) and Gas Chromatography/Mass Spectrometry (GC/MS) with Selected Ion Monitoring (SIM).
                        </E>
                         Revision 1.0. EPA 600-R-08-101. Office of Research and Development, Cincinnati, OH. September 2008. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxi) USEPA. 2009a. 
                        <E T="03">Method 524.3—Measurement of Purgeable Organic Compounds in Water by Capillary Column Gas Chromatography/Mass Spectrometry.</E>
                         Version 1.0. EPA 815-B-09-009. Office of Ground Water and Drinking Water, Cincinnati, OH. June 2009. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P100J75C.PDF?Dockey=P100J75C.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxii) USEPA. 2009b. 
                        <E T="03">Method 557: Determination of Haloacetic Acids, Bromate, and Dalapon in Drinking Water by Ion Chromatography Electrospray Ionization Tandem Mass Spectrometry (IC-ESI-MS/MS).</E>
                         Version 1.0. Office of Water, Cincinnati, OH. September 2009. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P1005OKO.PDF?Dockey=P1005OKO.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxiii) USEPA. 2009c. 
                        <E T="03">Method 538—Determination of Selected Organic Contaminants in Drinking Water by Direct Aqueous Injection-Liquid Chromatography/Tandem Mass Spectrometry (DAI-LC/MS/MS).</E>
                         Version 1.0. EPA 600-R-09-149. Office of Research and Development, Cincinnati, OH. November 2009. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxiv) USEPA. 2010. 
                        <E T="03">Method 539—Determination of Hormones in Drinking Water by Solid Phase Extraction (SPE) and Liquid Chromatography Electrospray Ionization Tandem Mass Spectrometry (LC-ESI-MS/MS).</E>
                         Version 1.0. EPA 815-B-10-001. Office of Water, Cincinnati, OH. November 2010. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxv) USEPA. 2011. 
                        <E T="03">Method 523—Determination of Triazine Pesticides and their Degradates in Drinking Water by Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Version 1.0. EPA 815-R-11-002. Office of Water, Cincinnati, OH. February 2011. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P100J7D4.PDF?Dockey=P100J7D4.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxvi) USEPA. 2012. 
                        <E T="03">Method 525.3—Determination of Semivolatile Organic Chemicals in Drinking Water by Solid Phase Extraction and Capillary Column Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Version 1.0. EPA 600-R-12-010. Office of Research and Development, Cincinnati, OH. February 2012. Available at 
                        <E T="03">https://cfpub.epa.gov/si/si_public_record_report.cfm?Lab=NERL&amp;dirEntryId=241188.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxvii) USEPA. 2013a. 
                        <E T="03">Method 524.4—Measurement of Purgeable Organic Compounds in Water by Gas Chromatography/Mass Spectrometry Using Nitrogen Purge</E>
                         Gas. EPA 815-R-13-002. Office of Water, Cincinnati, OH. May 2013. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P100J7EE.PDF?Dockey=P100J7EE.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxviii) USEPA. 2013b. 
                        <E T="03">Method 540—Determination of Selected Organic Chemicals in Drinking Water by Solid Phase Extraction and Liquid Chromatography/Tandem Mass Spectrometry (LC/MS/MS).</E>
                         Version 1.0. EPA 600-R-13-119. Office of Research and Development, Cincinnati, OH. September 2013. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxix) USEPA. 2014. 
                        <E T="03">Method 1615—Measurement of Enterovirus and Norovirus Occurrence in Water by Culture and RT-qPCR.</E>
                         Version 1.3. Office of Research and Development, Cincinnati, OH. September 2014. Available at 
                        <E T="03">https://cfpub.epa.gov/si/si_public_record_report.cfm?dirEntryId=306930&amp;Lab=NERL.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxx) USEPA. 2015a. 
                        <E T="03">Method 530—Determination of Select Semivolatile Organic Chemicals in Drinking Water by Solid Phase Extraction and Gas Chromatography/Mass Spectrometry (GC/MS).</E>
                         Version 1.0. EPA 600-R-14-442. Office of Research and Development, Cincinnati, OH. January 2015. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxi) USEPA. 2015b. 
                        <E T="03">Method 544—Determination of Microcystins and Nodularin in Drinking Water by Solid Phase Extraction and Liquid Chromatography/Tandem Mass Spectrometry (LC/MS/MS).</E>
                         Version 1.0. EPA 600-R-14-474. Office of Research and Development, Cincinnati, OH. February 2015. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxii) USEPA. 2015c. 
                        <E T="03">Method 543—Determination of Selected Organic Chemicals in Drinking Water by On-Line Solid Phase Extraction-Liquid Chromatography/Tandem Mass Spectrometry (On-Line SPE-LC/MS/MS).</E>
                         Version 1.0. EPA 600-R-14-098. Office of Research and Development, Cincinnati, OH. March 2015. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi/P100MD0C.PDF?Dockey=P100MD0C.PDF.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxiii) USEPA. 2015d. 
                        <E T="03">Method 545: Determination of Cylindrospermopsin and Anatoxin-a in Drinking Water by Liquid Chromatography Electrospray Ionization Tandem Mass Spectrometry (LC/ESI-MS/MS).</E>
                         EPA 815-R-15-009. Office of Water, Cincinnati, OH. April 2015. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxiv) USEPA. 2015e. 
                        <E T="03">Method 541: Determination of 1-Butanol, 1,4-Dioxane, 2-Methoxyethanol and 2-Propen-1-ol in Drinking Water by Solid Phase Extraction and Gas Chromatography/Mass Spectrometry.</E>
                         EPA 815-R-15-011. Office of Water, Cincinnati, OH. November 2015. Available at 
                        <E T="03">https://nepis.epa.gov/Exe/ZyPDF.cgi?Dockey=P100NGIF.txt.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxv) USEPA. 2016a. 
                        <E T="03">Method 600/R-16/114-Analytical Protocol for Measurement of Extractable Semivolatile Organic Compounds Using Gas Chromatography/Mass Spectrometry.</E>
                         Office of Research and Development, Cincinnati, OH. July 2016. Available at 
                        <E T="03">https://cfpub.epa.gov/si/si_public_record_report.cfm?dirEntryId=337629&amp;Lab=NHSRC.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxvi) USEPA. 2016b. 
                        <E T="03">Method Validation of U.S. Environmental Protection Agency (EPA) Microbiological Methods of Analysis.</E>
                         FEM Document Number 2009-01. December 2016. Available at 
                        <E T="03">https://www.epa.gov/measurements-modeling/method-validation-and-peer-review-policies-and-guidelines.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxvii) USEPA. 2016c. 
                        <E T="03">Validation and Peer Review of U.S. Environmental Protection Agency Chemical Methods of Analysis.</E>
                         FEM Document Number 2005-01. February 2016. Available at 
                        <E T="03">https://www.epa.gov/measurements-modeling/method-validation-and-peer-review-policies-and-guidelines.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxviii) USEPA. 2019a. 
                        <E T="03">Method 533: Determination of Per- and Polyfluoroalkyl Substances in Drinking Water by Isotope Dilution Anion Exchange Solid Phase Extraction and Liquid Chromatography/Tandem Mass Spectrometry.</E>
                         EPA 815-B-19-020. Office of Water, Cincinnati, OH. November 2019. Available at 
                        <E T="03">https://www.epa.gov/dwanalyticalmethods.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxix) USEPA. 2019b. 
                        <E T="03">Technical Brief Innovative Research for a Sustainable Future: Perfluoroalkyl and Polyfluoroalkyl Substances (PFAS) Methods and guidance for sampling and analyzing water and other environmental media.</E>
                         EPA 600-F-17-022g. Office of Research and Development, Cincinnati, OH. March 2010. Available at 
                        <E T="03">https://www.epa.gov/sites/default/files/2019-12/documents/pfas_methods-sampling_tech_brief_23dec19_update.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxx) USEPA. 2020a. 
                        <E T="03">Method 537.1: Determination of Selected Per- and Polyfluorinated Alkyl Substances in Drinking Water by Solid Phase Extraction and Liquid Chromotography/Tandem Mass Spectrometry (LC/MS/MS).</E>
                         Version 2.0. EPA 600-R-20-006. Office of Research and Development, Cincinnati, OH. March 2010. Available at 
                        <E T="03">https://cfpub.epa.gov/si/si_public_record_report.cfm?dirEntryId=348508&amp;Lab=CESER&amp;simpleSearch=0&amp;showCriteria=2&amp;searchAll=537.1&amp;TIMSType=&amp;dateBeginPublishedPresented=03%2F24%2F2018.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxxi) USEPA. 2020b. 
                        <E T="03">Method 559—Determination of Nonylphenol and 4-Tert-Octylphenol in Drinking Water by Solid Phase Extraction and Liquid Chromatography/Tandem Mass Spectrometry (LC/MS/MS).</E>
                         Version 1.0. EPA 600-R-20-270. Office of Research and Development, Cincinnati, OH. September 2020. Available at 
                        <E T="03">https://cfpub.epa.gov/si/si_public_record_report.cfm?Lab=CESER&amp;dirEntryId=349691.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxxii) USEPA. 2022a. 
                        <E T="03">
                            Draft Method 1621: Screening Method for the Determination of Adsorbable Organic Fluorine (AOF) in Aqueous Matrices by Combustion Ion 
                            <PRTPAGE P="8598"/>
                            Chromatography (CIC).
                        </E>
                         EPA-821-D-22-0202. Office of Research and Development, Cincinnati, OH. April 2022. Available at 
                        <E T="03">https://www.epa.gov/system/files/documents/2022-04/draft-method-1621-for-screening-aof-in-aqueous-matrices-by-cic_0.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxxiii) USEPA. 2022b. Drinking Water Contaminant Candidate List 5—Final. 
                        <E T="04">Federal Register</E>
                        . Vol. 87, No. 218, p. 68060, November 14, 2022.
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxxiv) USEPA. 2023. Comptox Chemicals Dashboard v2.3.0. 
                        <E T="03">https://comptox.epa.gov/dashboard/chemical-lists/PFASSTRUCT</E>
                         (accessed January 24, 2024) PFAS Structure Lists.
                    </FP>
                    <FP SOURCE="FP-2">
                        (lxxxv) Wong, C. &amp; Coffin, S. 2022. 
                        <E T="03">Standard Operating Procedures for Extraction and Measurement by Infrared Spectroscopy of Microplastic Particles in Drinking Water.</E>
                         California State Water Resources Control Board. May 27, 2022. Available at 
                        <E T="03">https://www.waterboards.ca.gov/drinking_water/certlic/drinkingwater/documents/microplastics/swb-mp1-rev1.pdf.</E>
                    </FP>
                </EXTRACT>
                <SIG>
                    <NAME>Jennifer L. McLain,</NAME>
                    <TITLE>Director, Office of Ground Water and Drinking Water.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02247 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Parts 260, 261, and 270</CFR>
                <DEPDOC>[EPA-HQ-OLEM-2023-0085; FRL-9247-01-OLEM]</DEPDOC>
                <RIN>RIN 2050-AH27</RIN>
                <SUBJECT>Definition of Hazardous Waste Applicable to Corrective Action for Releases From Solid Waste Management Units</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This proposed rule would amend the definition of hazardous waste applicable to corrective action to address releases from solid waste management units at RCRA-permitted treatment, storage, and disposal facilities and make related conforming amendments, thereby providing clear regulatory authority to fully implement the Resource Conservation and Recovery Act (RCRA) statutory requirement that permitted facilities conduct corrective action to address releases not only of substances listed or identified as hazardous waste in the regulations but of any substance that meets the statutory definition of hazardous waste. The proposed rule would also provide notice of EPA's interpretation that the statutory definition of hazardous waste applies to corrective action for releases from solid waste management units at permitted and interim status facilities.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before March 11, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, identified by Docket ID No. EPA-HQ-OLEM-2023-0085, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal: https://www.regulations.gov/</E>
                         (our preferred method). Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Environmental Protection Agency, EPA Docket Center, RCRA Docket, Mail Code 28221T, 1200 Pennsylvania Avenue NW, Washington, DC 20460.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery/Courier:</E>
                         EPA Docket Center, WJC West Building, Room 3334, 1301 Constitution Avenue NW, Washington, DC 20004. The Docket Center's hours of operations are 8:30 a.m.-4:30 p.m., Monday-Friday (except Federal Holidays).
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the Docket ID No. for this rulemaking. Comments received may be posted without change to 
                        <E T="03">https://www.regulations.gov/,</E>
                         including any personal information provided. For detailed instructions on sending comments and additional information on the rulemaking process, see the “Public Participation” heading of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this document.
                    </P>
                    <P>
                        Submit your comments, identified by Docket ID No. EPA-HQ-OLEM-2023-0085, at 
                        <E T="03">https://www.regulations.gov</E>
                         (our preferred method), or the other methods identified in the 
                        <E T="02">ADDRESSES</E>
                         section of this document. Once submitted, comments cannot be edited or removed from the docket. EPA may publish any comment received to its public docket. Do not submit electronically any information you consider to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. Multimedia submissions (audio, video, etc.) must be accompanied by a written comment. The written comment is considered the official comment and should include discussion of all points you wish to make. EPA will generally not consider comments or comment contents located outside of the primary submission (
                        <E T="03">i.e.,</E>
                         on the web, cloud, or other file sharing system). For additional submission methods, the full EPA public comment policy, information about CBI or multimedia submissions, and general guidance on making effective comments, please visit 
                        <E T="03">https://www.epa.gov/dockets/commenting-epa-dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Barbara Foster, Program Information and Implementation Division, Office of Resource Conservation and Recovery (5303T)) Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington DC, 20460, 202-566-0382, 
                        <E T="03">foster.barbara@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Authority</HD>
                <P>These regulations are promulgated under the authority of sections 2002(a), 3004(u) and (v), and 3008(h) of the Resource Conservation and Recovery Act, as amended, 42 U.S.C. 6912(a), 6924(u) and (v), and 6928(h).</P>
                <HD SOURCE="HD1">II. Background</HD>
                <HD SOURCE="HD2">A. Overview of RCRA Corrective Action Requirements Applicable to Releases From Solid Waste Management Units</HD>
                <P>The 1984 Hazardous and Solid Waste Amendments (HSWA) to the Resource Conservation and Recovery Act (RCRA) expanded EPA's authority to address releases of hazardous waste and constituents at RCRA treatment, storage, and disposal facilities.</P>
                <P>Sections 3004(u) and (v) of RCRA, added to the statute by HSWA, provided for corrective action requirements at permitted facilities. Section 3004(u) directed EPA to require corrective action for “all releases of hazardous waste or constituents from any solid waste management unit” at permitted hazardous waste treatment, storage, or disposal facilities regardless of the time at which waste was placed in the units. Section 3004(v) directed EPA to require that corrective action be taken beyond facility boundaries where necessary to protect human health and the environment unless facility owners/operators demonstrate to the Agency's satisfaction that, despite their best efforts, they were unable to obtain the necessary permission to undertake off-site corrective action.</P>
                <P>Section 3008(h), also added by HSWA, provided EPA authority to require corrective action for “a release of hazardous waste into the environment from a facility” authorized to operate under interim status.</P>
                <HD SOURCE="HD2">B. Brief History of Regulatory Actions Implementing HSWA and Leading to This Proposed Rule</HD>
                <P>
                    Prior to HSWA, regulatory requirements for corrective action to address releases of hazardous waste and constituents were limited in scope. The regulations in 40 CFR part 264 Subpart F imposed requirements on owners and 
                    <PRTPAGE P="8599"/>
                    operators of regulated units 
                    <SU>1</SU>
                    <FTREF/>
                     to address releases to groundwater. These regulations included a corrective action requirement for releases to groundwater of those hazardous waste and hazardous constituents that are identified in the regulations. This corrective action requirement did not extend to releases to other media, or to other solid waste management units.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         A regulated unit is defined in § 264.90 as a surface impoundment, waste pile, and land treatment unit or landfill that receives hazardous waste after July 26, 1982.
                    </P>
                </FTNT>
                <P>
                    HSWA expanded EPA's corrective action authority to address not only releases to the groundwater from regulated units but all releases of hazardous waste and constituents from solid waste management units and authorized the Agency to issue regulations. On July 15, 1985, EPA issued a final rule that amended EPA's hazardous waste regulations to reflect certain of the new statutory provisions of HSWA (referred to as the 1985 Codification Rule because it codified a number of HSWA requirements).
                    <SU>2</SU>
                    <FTREF/>
                     That final rule added to the regulations in Part 264 a new § 264.101, which largely mirrored the language in section 3004(u) and required that permits require facility-wide corrective action to address releases of hazardous waste and constituents from solid waste management units. The Agency later amended § 264.101 to implement section 3004(v), which requires owners and operators to institute corrective action beyond the facility boundary where necessary to protect human health and the environment unless the owner or operator is denied access to adjacent lands despite their best efforts.
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Hazardous Waste Management System; Final Codification Rule, 50 FR 28702, July 15, 1985.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Hazardous Waste; Codification Rule for the 1984 Amendments 52 FR 45788, December 1, 1987.
                    </P>
                </FTNT>
                <P>Section 260.10 provides definitions for terms used in 40 CFR parts 260 through 273. The definition of “hazardous waste” in § 260.10 refers to the definition in § 261.3, that is, it applies the regulatory definition to those parts. Under that definition, only solid wastes that are listed in the regulations or exhibit one of the four regulatory hazardous waste characteristics (ignitability, corrosivity, reactivity, and toxicity) are hazardous waste. When EPA codified section 3004(u) in the final 1985 Codification Rule, the Agency did not discuss the question of whether the regulatory definition of hazardous waste, generally applicable to 40 CFR part 264, should also apply to the new corrective action authority.</P>
                <P>
                    On July 1, 1990,
                    <SU>4</SU>
                    <FTREF/>
                     EPA proposed requirements for a new Subpart S in 40 CFR part 264 that would establish in detail the procedures and standards for implementing sections 3004(u) and (v) including requirements for conducting remedial investigations, evaluating potential remedies, and selecting and implementing remedies at RCRA facilities.
                    <SU>5</SU>
                    <FTREF/>
                     In that proposed rule, EPA addressed the question of what definition of hazardous waste applies to corrective action for releases from solid waste management units.
                    <SU>6</SU>
                    <FTREF/>
                     In the preamble, EPA stated its interpretation that “hazardous waste” in section 3004(u) denotes “hazardous waste” as defined in RCRA section 1004(5).
                    <SU>7</SU>
                    <FTREF/>
                     EPA explained that the term “hazardous waste” appearing in section 3004(u) is distinguished from the phrase “hazardous waste listed and identified,” which is used elsewhere in the statute to denote that subset of hazardous wastes specifically listed and identified by the Agency pursuant to section 3001 of RCRA. EPA stated that, under that interpretation, the remedial authority under section 3004(u) is not limited to releases of wastes identified as hazardous waste in 40 CFR part 261. Rather, it extends potentially to any substance meeting the statutory definition. EPA further stated that the use of the phrase “hazardous waste or constituents” in section 3004(u) indicated that Congress was particularly concerned that the Agency use the corrective action authority to address hazardous constituents.
                    <SU>8</SU>
                    <FTREF/>
                     EPA proposed to define hazardous constituents for purposes of Subpart S as those constituents listed on Appendix VIII of Part 261—Hazardous Constituents, or on Appendix IX of Part 264—Groundwater Monitoring List. EPA proposed moving § 264.101 to the new Subpart S and proposed a definition of hazardous waste that repeated the language in RCRA section 1004(5) and would be applicable to the new subpart. That proposed rule thus would have expressly applied the statutory definition of hazardous waste to corrective action for releases from solid waste management units required under EPA's regulations.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Corrective Action for Solid Waste Management Units at Hazardous waste Management Facilities; Proposed Rule, July 27, 1990, 55 FR 30798.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         As discussed below, many provisions of this proposed rule were not made final.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         1990 Subpart S Proposed Rule, 55 FR 30798 at 30809 (July 27, 1990).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Section 1004(5) provides—(5) The term “hazardous waste” means a solid waste, or combination of solid wastes, which because of its quantity, concentration, or physical, chemical, or infectious characteristics may:
                    </P>
                    <P>(A) cause, or significantly contribute to an increase in mortality or an increase in serious irreversible, or incapacitating reversible, illness; or</P>
                    <P>(B) pose a substantial present or potential hazard to human health or the environment when improperly treated, stored, transported, or disposed of, or otherwise managed.</P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         1990 Subpart S Proposed Rule, 55 FR 30798 at 30809.
                    </P>
                </FTNT>
                <P>
                    The Agency promulgated a few elements of the 1990 Subpart S proposed rule on February 16, 1993.
                    <SU>9</SU>
                    <FTREF/>
                     These elements included final provisions for Corrective Action Management Units (CAMUs) and Temporary Units, and a definition of “facility” for corrective action. The remainder of the 1990 Subpart S proposed rule was not made final. However, EPA and authorized States began using the proposed rule and preamble as the primary guidance for the corrective action program soon after it was published.
                    <SU>10</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         Corrective Action Management Units and Temporary Units; Corrective Action Provisions Under Subtitle C, 58 FR 8658, February 16, 1993.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         Memorandum from Lisa K. Friedman to Regional Counsel RCRA Branch Chiefs, Regions 1-10 entitled “Use of Proposed Subpart S Corrective Action Rule as Guidance Pending Promulgation of the Final Rule, March 27, 1991, available at: 
                        <E T="03">https://rcrapublic.epa.gov/files/13461.pdf,</E>
                         and in the docket for this rulemaking.
                    </P>
                </FTNT>
                <P>
                    On May 1, 1996, EPA issued an Advance Notice of Proposed Rulemaking (“Subpart S ANPR”) that, among other things, solicited comment on whether to issue detailed regulations along the lines of the 1990 Subpart S proposal to implement the Corrective Action Program. In the 1996 Subpart S ANPR, EPA repeated its interpretation that the term “hazardous waste” in section 3004(u) includes all wastes that are hazardous within the statutory definition in RCRA section 1004(5), not just those that are identified by EPA in regulation.
                    <SU>11</SU>
                    <FTREF/>
                     EPA again stated its position regarding the importance of addressing hazardous constituents through corrective action in the 1996 Subpart S ANPR.
                    <SU>12</SU>
                    <FTREF/>
                     The 1996 Subpart S ANPR replaced the 1990 Subpart S proposed rule as the primary guidance for much of the Corrective Action Program.
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         Corrective Action for Releases from Solid Waste Management Units at Hazardous Waste Management Facilities, May 1, 1996, 61 FR 19432 at 19443.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         Subpart S ANPR, May 1, 1996, 85 FR at 19432 at 19443.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         Memorandum from Elliott P. Laws and Steven A. Herman to RCRA/CERCLA Senior Policy Managers entitled “Use of the Corrective Action Advance Notice of Proposed Rulemaking as Guidance,” January 17, 1997, found in the docket for this rulemaking.
                    </P>
                </FTNT>
                <P>
                    On October 7, 1999, the Agency issued a 
                    <E T="04">Federal Register</E>
                     notice withdrawing the 1990 Subpart S 
                    <PRTPAGE P="8600"/>
                    proposed rule in part.
                    <SU>14</SU>
                    <FTREF/>
                     EPA explained that experience implementing the Corrective Action Program to date had demonstrated that more detailed regulations were not necessary to carry out the Agency's duties under RCRA 3004(u) and (v).
                    <SU>15</SU>
                    <FTREF/>
                     EPA did not withdraw the proposal with respect to two corrective action jurisdictional issues, because it concluded that those were issues about which the Agency had expressed concern regarding the status quo or raised questions that had not been definitively answered by the Agency.
                    <SU>16</SU>
                    <FTREF/>
                     The notice expressly contrasted those issues with the definition of hazardous waste or constituents, as to which EPA had not expressed concerns or raised questions that it had not definitively answered.
                    <SU>17</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         Corrective Action for Solid Waste Management Units at Hazardous Waste Management Facilities, Partial Withdrawal of Rulemaking Proposal, 64 FR 54604 (October 7, 1999).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         EPA stated several reasons for its decision to withdraw provisions of the 1990 Subpart S proposed rule. EPA had learned that additional final regulations were not necessary to authorize State programs and was concerned that regulations would disrupt State programs that had been authorized. EPA also recognized that its early goal of consistent application of rules and standards at all sites is not always appropriate given the diversity of facilities subject to corrective action. See the discussion of this issue in the 1990 Subpart S proposed rule 64 FR 54604 at 54605. The proposal to codify the statutory definition of hazardous waste was among the provisions of the proposed rule that was withdrawn.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         64 FR at 54606-7. The two aspects of the proposal EPA preserved were the definition of “facility” for corrective action purposes and the question of who is responsible for corrective action when there is a transfer of facility property.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         Id.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Litigation Pertaining to the Scope of Hazardous Waste Subject to Corrective Action</HD>
                <P>
                    In December 2018, the New Mexico Environment Department issued a hazardous waste facility permit to Cannon Air Force Base under its RCRA-authorized hazardous waste authorities.
                    <SU>18</SU>
                    <FTREF/>
                     The permit, among other things, imposed corrective action requirements for perfluoroalkyl substances at the facility. Per- and polyfluoroalkyl substances (PFAS) are not listed or identified as hazardous wastes or hazardous constituents in EPA or New Mexico authorized regulations. In January 2019, the United States, on behalf of Air Force, challenged the permit in the Federal District Court for the District of New Mexico. In the complaint, the United States took the position that New Mexico's corrective action regulation—which mirrors the federal regulation—does not authorize corrective action for substances that are not listed or characteristic hazardous wastes under the State's regulations, even if they might be hazardous under the broader statutory definition.
                    <SU>19</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         New Mexico is one of the 44 States (along with one territory) authorized to implement corrective action (1985 Codification Rule provisions).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         The New Mexico Hazardous Waste Act (HWA) contains a provision defining corrective action as “an action taken in accordance with rules of the [New Mexico environmental improvement board] to investigate, minimize, eliminate or clean up a release. . . .” N.M. Stat. Ann. Section 74-4-3-C. RCRA does not contain a comparable provision, so the laws governing corrective action under RCRA and the HWA are not identical.
                    </P>
                </FTNT>
                <P>
                    The case caused EPA to take a fresh look at its regulations.
                    <SU>20</SU>
                    <FTREF/>
                     As further described below, EPA now recognizes that, as a result of EPA's decision not to make final the hazardous waste definition portion of the Subpart S proposal, EPA's corrective action regulation does not fully and clearly reflect the scope of corrective action as required by RCRA 3004(u) and (v)). This proposed regulation would better align the regulation with the statutory requirement.
                </P>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         The court dismissed the case on jurisdictional grounds in August 2022. The United States, on behalf of Air Force, has appealed the case to the United States Court of Appeals for the Tenth Circuit.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">D. New Mexico Rulemaking Petition</HD>
                <P>
                    On June 23, 2021, the Governor of New Mexico filed a petition with EPA requesting a timely listing of PFAS, as a class of chemicals, as hazardous wastes under the RCRA Subtitle C regulations, or in the alternative, a listing of individual PFAS chemicals as hazardous wastes under the regulations.
                    <SU>21</SU>
                    <FTREF/>
                     EPA acted upon the Governor of New Mexico's petition with an October 26, 2021, letter. EPA indicated in that letter that it would be initiating the rulemaking process for two rulemakings.
                    <SU>22</SU>
                    <FTREF/>
                     This proposal, along with EPA's proposal titled 
                    <E T="03">Listing of Specific PFAS as RCRA Hazardous Constituents,</E>
                     constitutes initiation of those rulemakings. While this proposed rule would not directly address PFAS, it would facilitate the use of RCRA corrective action authority to address emerging contaminants such as PFAS, as well as other non-regulatory hazardous waste, at RCRA permitted treatment, storage, and disposal facilities.
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         Petition from the Governor of New Mexico to the Administrator of EPA concerning action on PFAS under RCRA. June 23, 2021, available at: 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/508compliant_ezd5442262_2021-06-23-governor-letter-to-epa-for-pfas-petition.pdf-incoming-document.pdf</E>
                        , and in the docket for this rulemaking. The New Mexico petition incorporated by reference two earlier petitions submitted to EPA by Public Employees for Environmental Responsibility (PEER), submitted on September 19, 2019, available at: 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-09/peer_pfas_rulemaking_petition_metadata_added.pdf,</E>
                         and in the docket for this rulemaking; and Environmental Law Clinic of University of California, Berkeley (UC Berkeley), submitted on January 15, 2020, available at: 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-09/pfas_petition_for_haz_waste_jan_2020_metadata_added.pdf</E>
                         and in the docket for this rulemaking.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         EPA Response to New Mexico Governor's Petition on PFAS, October 26, 2021, available at: 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/oct_2021_response_to_nm_governor_pfas_petition_corrected.pdf,</E>
                         and in the docket for this rulemaking.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">III. Summary of This Proposed Rule</HD>
                <P>This proposed rule would amend the regulations applicable to RCRA treatment, storage, and disposal facilities in two related respects. First, it would amend the definition of hazardous waste applicable to corrective action. Specifically, it would amend the definition in § 260.10 to expressly apply the RCRA section 1004(5) statutory definition of hazardous waste to corrective action requirements under § 264.101 and 40 CFR part 264 Subpart S. Similarly, it would amend the identical definition in the hazardous waste facility permitting regulations, § 270.2, to expressly apply the statutory definition of hazardous waste to the requirements relating to corrective action in § 270.14(d). These proposed revisions would more clearly provide EPA authority to address, through corrective action for solid waste management units, releases of the full universe of substances that the statute intended—not only hazardous waste and hazardous constituents listed or identified in the regulations, but all substances that meet the definition of hazardous waste in RCRA section 1004(5) at a facility.</P>
                <P>Second, this proposed rule would add RCRA sections 3004(u) and (v) and 3008(h) to the statutory authorities identified in § 261.1(b)(2). That section provides that the statutory definitions of solid and hazardous waste govern the scope of EPA's authority under certain sections of RCRA, not the more limited 40 CFR part 261 regulatory definitions. These revisions provide notice of and codify the Agency's interpretation of the statute—that it provides authority to address releases from solid waste management units of all substances that meet the definition of hazardous waste under the statute.</P>
                <HD SOURCE="HD1">IV. Section-by-Section Analysis</HD>
                <HD SOURCE="HD2">A. Revisions to the Definitions in §§ 260.10 and 270.2</HD>
                <P>
                    The definitions in 40 CFR 260.10 apply to 40 CFR parts 260 thru 273. The § 260.10 definition of hazardous waste refers to the definition in § 261.3 of the regulations, that is, the regulatory 
                    <PRTPAGE P="8601"/>
                    definition. Because the § 260.10 definition is the regulatory definition, when the Agency codified sections 3004(u) and (v) in § 264.101, the regulatory definition of hazardous waste became linked to solid waste management unit corrective action. That result is not consistent with EPA's longstanding interpretation of the scope of sections 3004(u) and (v).
                </P>
                <P>
                    That result also is not consistent with the direction EPA has provided to Corrective Action Program implementers, with EPA statements regarding its authority, or with implementation of the Corrective Action Program to date. As described above, the primary guidance for the Corrective Action Program—the 1990 Subpart S proposed rule and later the 1996 Subpart S ANPR—interpret EPA's authority under sections 3004(u) and (v) and 3008(h) as extending to releases of any substance that meets the statutory definition of hazardous waste. EPA has consistently maintained this interpretation. For example, in explaining a decision not to list used oil as hazardous waste, EPA observed that “[u]sed oils are subject to the corrective action requirements of RCRA subtitle C, including sections 3004(u) and (v) and 3008(h) . . .” 
                    <SU>23</SU>
                    <FTREF/>
                     In addition, a July 24, 2002, final rule that, among other things, excluded hazardous secondary materials used to make zinc fertilizers from the regulatory definition of solid waste, again stated EPA's position that section 3004(u) uses the broader statutory definition of hazardous waste and is not limited by the regulatory definition.
                    <SU>24</SU>
                    <FTREF/>
                     More recently, the Agency PFAS Action Plan cited RCRA sections 3004(u) and (v) and section 3008(h) as potential authorities to use to address or prevent PFAS contamination.
                    <SU>25</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         57 FR 21524, 21529 (May 20, 1992).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         Zinc Fertilizers Made From Recycled Hazardous Secondary Materials, 67 FR 48393 at 48398.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         EPA's Per- and Polyfluoroalkyl Substances (PFAS) Action Plan, February 2019 Page 27, 
                        <E T="03">https://www.epa.gov/sites/default/files/2019-02/documents/pfas_action_plan_021319_508compliant_1.pdf.</E>
                    </P>
                </FTNT>
                <P>
                    EPA's model order developed for implementation of corrective action under section 3008(h) also relies on the statutory definition.
                    <SU>26</SU>
                    <FTREF/>
                     EPA and authorized States have included conditions in RCRA permits and section 3008(h) orders requiring corrective action to address substances that were not regulatory hazardous wastes or hazardous constituents.
                    <SU>27</SU>
                    <FTREF/>
                     Further, EPA has issued a limited number of RCRA permits that expressly apply the statutory hazardous waste definition to corrective action.
                    <SU>28</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         Model Resource Conservation and Recovery Act Section 3008(h) Administrative Order on Consent, September 2016 can be found, with transmittal memo, at 
                        <E T="03">https://www.epa.gov/sites/default/files/2016-10/documents/rcra3008h-aoc-mod-mem-2016.pdf.</E>
                         The 2016 model order updated a model order issued in 1993, which also relied on the statutory hazardous waste definition. Available in the docket for this rulemaking and at: 
                        <E T="03">https://nepis.epa.gov/Exe/ZyNET.exe/9100UF01.TXT?ZyActionD=ZyDocument&amp;Client=EPA&amp;Index=1991+Thru+1994&amp;Docs=&amp;Query=&amp;Time=&amp;EndTime=&amp;SearchMethod=1&amp;TocRestrict=n&amp;Toc=&amp;TocEntry=&amp;QField=&amp;QFieldYear=&amp;QFieldMonth=&amp;QFieldDay=&amp;IntQFieldOp=0&amp;ExtQFieldOp=0&amp;XmlQuery=&amp;File=D%3A%5Czyfiles%5CIndex%20Data%5C91thru94%5CTxt%5C00000026%5C9100UF01.txt&amp;User=ANONYMOUSamp;Password=anonymous&amp;SortMethod=h%7C-&amp;MaximumDocuments=1&amp;FuzzyDegree=0&amp;ImageQuality=r75g8/r75g8/x150y150g16/i425&amp;Display=hpfr&amp;DefSeekPage=x&amp;SearchBack=ZyActionL&amp;;Back=ZyActionS&amp;BackDesc=Results%20page&amp;MaximumPages=1&amp;ZyEntry=1&amp;SeekPage=x&amp;ZyPURL</E>
                         on page 4).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>27</SU>
                         For example: (1) Permits issued to ATK Bacchus (2019), ATK Bacchus-Nirop (2020), and ATK Promontory OP (2018) by the State of Utah; requirements to address perchlorate, which is not a regulatory hazardous waste or on EPA or Utah's hazardous constituent list; (2) Permit Modification issued to Chemours Washington Works by the West Virginia Department of Environmental Protection June 15, 2016, included requirements to address PFOA; and (3) Part I Permit issued to Expert Management Inc. Missouri Hazardous waste Management Facility, August 31, 2020, imposes corrective action requirements on several substances that are not regulatory hazardous wastes or included in EPA's or Missouri's regulatory constituent lists: ammonia, fluoride, nitrate, perchlorate, and sulfate. These documents are available in the docket for this rulemaking.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>28</SU>
                         For example, a 2020 permit for the Penick Forest Products facility (title “HWSA Permit and Trans”) and a 2019 permit for the Chemours DeLisle Plant, both in Mississippi—define “hazardous waste” using the statutory definition text for corrective action purposes. See pp 11-12 of the first two attachments. These permits are available in the docket for this rulemaking.
                    </P>
                </FTNT>
                <P>
                    As discussed above, when the Agency issued the 1999 
                    <E T="04">Federal Register</E>
                     notice withdrawing most provisions of the 1990 Subpart S proposed rule, EPA determined that those provisions were not necessary to carry out EPA's duties under RCRA sections 3004(u) and (v). EPA has now concluded, however, that the regulatory provision of the Subpart S proposal that would have expressly applied the statutory definition of hazardous waste to the regulatory corrective action requirements for solid waste management units is necessary to facilitate implementation of the Agency's full authority under the statute.
                </P>
                <P>
                    EPA has come to realize that despite clear statements regarding the Agency's interpretation of the term “hazardous waste” in section 3004(u), the 40 CFR part 264 regulations can cause difficulties for program implementers issuing permit conditions for corrective action. The applicability of the regulatory definition of hazardous waste to 40 CFR part 264 may create confusion and thereby invite challenges to corrective action permit conditions that address releases of substances not listed or identified in the regulations as hazardous waste or constituents. Moreover, as a matter of good government, EPA's regulation should accurately and clearly reflect the requirements of the implementing statute, as interpreted by EPA. Therefore, EPA is proposing 
                    <SU>29</SU>
                    <FTREF/>
                     to modify the regulations in § 260.10 to make clear that the statutory definition of hazardous waste applies to corrective action for releases of hazardous waste from solid waste management units.
                </P>
                <FTNT>
                    <P>
                        <SU>29</SU>
                         Because the proposed statutory definition of hazardous waste is among the provisions of the 1990 Subpart S proposed rule that was withdrawn in the 1996 withdrawal notice, EPA is reproposing that the statutory definition of hazardous waste apply to corrective action to address solid waste management units.
                    </P>
                </FTNT>
                <P>EPA also is proposing a conforming definitional amendment. Specifically, in § 270.2, EPA is proposing to expressly apply the statutory definition of hazardous waste to the permitting requirements in § 270.14(d), which support § 264.101. Section 270.14(d) sets forth the information that is required in permit applications for each solid waste management unit at a facility.</P>
                <P>
                    EPA's interpretation of RCRA sections 3004(u) and (v) implements the plain language of RCRA. “Hazardous waste” is a defined term, and RCRA section 3004(u) uses that term. This usage contrasts with other provisions of RCRA Subtitle C, whose scope is limited to hazardous waste identified or listed under Subtitle C.
                    <SU>30</SU>
                    <FTREF/>
                     While EPA has referred to its reading of RCRA section 3004(u) as an interpretation, it is arguably compelled by the language of the statute, since it simply applies the statutory definition to a term used in the provision. RCRA section 3004(v) does not expressly speak to the scope of corrective action required beyond the facility boundary,
                    <SU>31</SU>
                    <FTREF/>
                     but there is no textual or logical basis to believe that the phrase “corrective action” in that section means something other than the 
                    <PRTPAGE P="8602"/>
                    phrase as used in the preceding, simultaneously enacted section.
                </P>
                <FTNT>
                    <P>
                        <SU>30</SU>
                         For example, RCRA sections 3002(a), 3003(a), 3004(a), and 3005(a)—which, respectively, govern the generation of hazardous waste; transportation of such waste; treatment, storage, and disposal of such waste; and permitting of facilities for the treatment, storage, and disposal of such waste—are limited in scope to hazardous waste identified or listed under Subtitle C.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>31</SU>
                         Section 3004(v) correctly limits the facilities subject to beyond-the-boundary corrective action to “facilities for the treatment, storage, or disposal, of hazardous waste listed or identified under section 3001,” but it does not speak to the scope of substances subject to such corrective action.
                    </P>
                </FTNT>
                <P>To the extent EPA's reading is not compelled, it is clearly the best reading of the statute. As used in RCRA, the phrase “hazardous waste” governs the scope of investigative and response authorities that are developed and applied on a case-by-case basis. In addition to section 3004(u), the phrase is used, among other places, in section 3008(h), to define the scope of EPA's authority to order corrective action at interim status facilities; section 3007, to define the scope of EPA's Subtitle C inspection and information gathering authorities; section 3013, to define the scope of EPA's Subtitle C authority to order monitoring, analysis, and testing; and section 7003, to define the scope of EPA's imminent hazard authority. As discussed briefly below, EPA codified its interpretation of “hazardous waste” as used in sections 3007, 3013, and 7003 decades ago. In contrast, the phrase “hazardous waste identified or listed” under Subtitle C is used to define the scope of the uniform regulatory requirements applicable to the generation, transportation, treatment, storage, and disposal of hazardous wastes that EPA has identified or listed by regulation, pursuant to RCRA section 3001.</P>
                <P>In imposing corrective action requirements on a non-regulatory substance under the amended regulation, a permit writer would need to develop, and present for public comment, an administrative record supporting any conclusion that the substance meets or may meet the statutory hazardous waste definition, as briefly discussed below in Section IV.B of this preamble. Any final permit conditions would be subject to administrative and/or judicial challenge to the same extent as other permit conditions.</P>
                <P>EPA solicits comment on its proposed revisions to the definition of hazardous waste in § 260.10 for purposes of corrective action.</P>
                <HD SOURCE="HD2">B. Revisions to § 261.1(b)(2)</HD>
                <P>
                    Section 261.1(b)(2) 
                    <SU>32</SU>
                    <FTREF/>
                     provides notice that the Agency's authority under sections 3007, 3013, and 7003 of RCRA is not limited to solid waste and hazardous waste identified in the regulations but extends to include solid and hazardous wastes under the definitions in the statute. This proposed rule would add RCRA sections 3004(u) and (v) and RCRA section 3008(h) to § 261.1(b)(2) to clarify that the statutory definitions of solid waste and hazardous waste apply to those RCRA sections as well.
                </P>
                <FTNT>
                    <P>
                        <SU>32</SU>
                         This section of the regulations provides: “This part identifies only some of the materials which are solid wastes and hazardous wastes under sections 3007, 3013, and 7003 of RCRA. A material which is not defined as a solid waste in this part, or is not a hazardous waste identified or listed in this part, is 
                        <E T="03">still</E>
                         a solid waste and a hazardous waste for purposes of these sections if:
                    </P>
                    <P>
                        (i) In the case of sections 3007 and 3013, EPA has reason to believe that the material may be a solid waste within the meaning of section 1004(27) of RCRA and a hazardous waste 
                        <E T="03">within the meaning of section 1004(5) of RCRA;</E>
                         or
                    </P>
                    <P>
                        (ii) In the case of section 7003, 
                        <E T="03">the statutory elements</E>
                         are established” (emphasis added).
                    </P>
                </FTNT>
                <P>
                    EPA established § 261.1(b)(2), in a final rule issued in May 1980,
                    <SU>33</SU>
                    <FTREF/>
                     to avoid confusion on several points. The provision made clear that the scope of the Agency's authority under the statutory provisions identified in that section is determined by the statutory definitions of solid and hazardous waste, not by the 40 CFR part 261 definitions that govern the Subtitle C hazardous waste management program. With respect to the hazardous waste definition, EPA explained: “Unlike Sections 3002 through 3004 and Section 3010, Congress did not confine the operations of Sections 3007 and 7003 
                    <SU>34</SU>
                    <FTREF/>
                     to “hazardous wastes `
                    <E T="03">identified or listed under this subtitle</E>
                    '. . . . To avoid future confusion on this point, EPA has stated it explicitly in § 261.1(b).” 
                    <SU>35</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>33</SU>
                         Hazardous Waste Management System: General, 45 FR 33084, May 19, 1980. EPA revised this section in 1985 see 50 FR 614, January 4, 1985.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>34</SU>
                         The reference to RCRA 3013 was added to this section in a 1985 rulemaking. 50 FR 614, January 4, 1985.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>35</SU>
                         45 FR 33084, 33090 (May 19, 1980) (emphasis in original).
                    </P>
                </FTNT>
                <P>Because § 261.1(b)(2)(i) identifies information-gathering authorities and § 261.1(b)(2)(ii) identifies remediation and other response authorities, and consequently a different level of finding is required under each of these sections, EPA is proposing to add sections 3004(u) and (v) and section 3008(h) to both sections.</P>
                <P>
                    Section 261.1(b)(2)(i) states that a material that is not a regulatory solid waste or a regulatory hazardous waste is still a solid waste and a hazardous waste for purposes of sections 3007 and 3013 if EPA has reason to believe that the material 
                    <E T="03">may be</E>
                     a solid waste within the meaning of 1004(27) or a hazardous waste within the meaning of section 1004(5). This provision describes EPA's authority to use the investigative and information gathering authorities provided in those statutory sections, which, among other things, enable EPA to gather information to determine if a substance is in fact a solid waste or a hazardous waste under the statute. Consistent with this regulatory text, EPA is proposing to add sections 3004(u) and (v) and section 3008(h) to the existing § 261.1(b)(2)(i) to explicitly state EPA's authority to impose requirements to implement the investigative stages of corrective action where the findings required by the provision are met. EPA would not rely solely on the findings described in this provision to require remediation activities.
                </P>
                <P>Section 261.1(b)(2)(ii) states that a material is a solid waste and a hazardous waste for purposes of RCRA section 7003 if the statutory elements are established. This paragraph describes EPA's authority to require remediation activities or other response measures under this section where the statutory definition of solid waste or hazardous waste is established. EPA is proposing to add sections 3004(u) and (v) and section 3008(h) to existing § 261.1(b)(2)(ii) to explicitly state EPA's authority to require remediation activities beyond the investigative stages of corrective action where the findings required by that section are met.</P>
                <P>EPA does not believe that the addition of sections 3004(u) and (v) and section 3008(h) to § 261.1(b) would impose additional requirements on facilities. As described above, these amendments to § 261.1(b) would provide clarity by expressly stating the Agency's statutory authority under the specific RCRA sections listed.</P>
                <P>EPA solicits comment on the proposed revisions to § 261.1(b).</P>
                <HD SOURCE="HD1">V. Impact of the Proposed Rule on Corrective Action Program Implementation</HD>
                <P>In developing this proposed rule, EPA anticipated how the rule might affect implementation of the Corrective Action Program, for example, whether it would increase the issuance of permit conditions to address releases of substances not identified or listed in the regulations, and/or whether it would redirect the program away from its current focus on releases of identified or listed substances. EPA does not expect these impacts.</P>
                <P>
                    EPA expects that the proposed rule would facilitate corrective action to address substances that meet the statutory definition of hazardous waste, but are not regulatory hazardous waste, by providing clear regulatory authority and would thereby minimize the likelihood of challenges to corrective action requirements. EPA does not, however, expect that an increase in permit conditions to address corrective action will be attributable to the regulatory authority proposed in this rule. EPA has long held the position that 
                    <PRTPAGE P="8603"/>
                    section 3004(u) provides authority to address statutory hazardous waste and, since 1990, has consistently instructed regional and State implementers that the corrective action authority reaches such waste. In addition, Corrective Action Program implementers have had authority to include corrective action conditions in permits either through State cleanup regulations or through the authority provided by § 270.32(b)(2), EPA's omnibus authority, and authorized State analogues.
                    <SU>36</SU>
                    <FTREF/>
                     In addition, as was discussed above, EPA has corrective action authority under section 3008(h) to address releases of statutory hazardous waste. Moreover, cleanup at RCRA treatment, storage, and disposal facilities also can be required or conducted pursuant to the Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA).
                </P>
                <FTNT>
                    <P>
                        <SU>36</SU>
                         Section 270.32(b)(2) provides: “Each permit issued under section 3005 of this act shall contain terms and conditions as the administrator or State Director determines necessary to protect human health and the environment.” EPA has long recognized the appropriateness of use of the omnibus authority to ensure the objectives of section 3004(u) are realized. In the 1996 Subpart S ANPR, EPA pointed out that Congress enacted the two authorities in the same HSWA amendments, 61 FR at 19433. EPA cited to the omnibus provision in explaining EPA's authority to require cleanup of releases from areas that do not qualify as solid waste management units. EPA stated: “Given the legislative history of RCRA section 3004(u), which emphasizes that RCRA facilities should be adequately cleaned up, in part, to prevent creation of new Superfund sites, EPA believes that corrective action authorities can be used to address all unacceptable risks to human health or the environment from RCRA facilities. In the permitting context, remediation of non-SWMU related releases may be required under the `omnibus' authority.” Id. at 19443.
                    </P>
                </FTNT>
                <P>In the process of developing this proposed rule, the Corrective Action Program gathered permits that impose corrective action requirements to address substances not listed or identified in the regulations as hazardous waste or constituents and found very few. EPA's understanding is that, although permit writers possess authority to require investigation and cleanup of substances that are not regulatory hazardous wastes or constituents, they have generally focused the Corrective Action Program on addressing releases of substances that are identified in the regulations. Given that the ability to address substances that are not regulatory hazardous waste has been available to program implementers in the past, EPA has no reason to expect that those substances, in general, would be addressed through corrective action more frequently in the future as a result of this proposed rule.</P>
                <P>
                    At the same time, EPA expects that the Agency's attention on addressing risks associated with PFAS 
                    <SU>37</SU>
                    <FTREF/>
                     will likely result in additional corrective action to address releases of those substances. EPA also expects that such increased corrective action activity would be supported principally not by this rule, but by the companion rule that EPA is developing to list a set of those substances as hazardous constituents in 40 CFR part 261 Appendix VIII.
                    <SU>38</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>37</SU>
                         For example, PFAS Strategic Roadmap, EPA's Commitment to Action 2021-2024, 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/pfas-roadmap_final-508.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>38</SU>
                         The PFAS addressed in the proposed rule are: Perfluorobutanoic acid (PFBA), Perfluorobutanesulfonic acid (PFBS), Perfluorodecanoic acid (PFDA), Perfluorohexanoic acid (PFHxA), Perfluorohexanesulfonic acid (PFHxS), Perfluorononanoic acid (PFNA), Perfluorooctanoic acid (PFOA), Perfluorooctanesulfonic acid (PFOS), and Hexafluoropropylene oxide-dimer acid (HFPO-DA or GenX. All references to the nine PFAS in this notice are meant to include their salts and linear and branched structural isomers. EPA intends to process these two rulemakings in tandem, and EPA's expectation that increased corrective action activity for these nine PFAS would be supported by the Appendix VIII rule is premised on the assumption that the two rules will be made final at or around the same time.
                    </P>
                </FTNT>
                <P>
                    In the 1990 Subpart S proposed rule discussed above, EPA stated its belief that the use of the phrase “hazardous waste or constituents” in section 3004(u) indicates that Congress was particularly concerned that the Agency use its corrective action authority to address hazardous constituents and stated that the term “hazardous constituents” in section 3004(u) means those constituents found in 40 CFR part 261 Appendix VIII.
                    <SU>39</SU>
                    <FTREF/>
                     Thus, hazardous constituents listed on 40 CFR part 261 Appendix VIII are routinely assessed for and addressed as part of the corrective action process.
                </P>
                <FTNT>
                    <P>
                        <SU>39</SU>
                         EPA also proposed in that rule to include within the definition of hazardous constituents those constituents identified in Appendix IX to 40 CFR part 264. See: 55 FR 30798 at 30809.
                    </P>
                </FTNT>
                <P>As a result of the PFAS Appendix VIII rulemaking, nine PFAS would be among the hazardous constituents expressly identified for consideration in RCRA facility assessments and investigations and, where necessary, cleanup through the corrective action process. EPA expects that this set of PFAS are those most likely to be addressed through corrective action, and that, if these specific PFAS are listed as hazardous constituents, corrective action to address those substances will be supported by their 40 CFR part 261 Appendix VIII listing, rather than the regulatory authority that would be provided by this proposed rule. EPA solicits comment on that expectation.</P>
                <P>EPA also solicits comment on whether the potential impacts of this rulemaking may be affected by the availability of other authorities that program implementers might rely on to satisfy corrective action requirements to address PFAS at RCRA facilities including other RCRA authorities such as omnibus permitting authority and RCRA section 7003, and CERCLA.</P>
                <P>As discussed above, EPA is proposing this rule to more clearly provide EPA authority to address, through RCRA corrective action for solid waste management units, releases of the full universe of substances that the statute intended. EPA believes that the regulations would, as a result of this rule, accurately reflect what the statute authorizes and requires, as interpreted by EPA. Finally, EPA believes that by providing clear regulatory authority, the proposed rule, if made final, would minimize the likelihood of challenges to corrective action requirements. EPA solicits comment on its understanding of the impact of this proposed rulemaking on its ability to effectively issue permit conditions to address statutory hazardous waste, and on whether there are possible alternatives that would achieve the benefits of this regulation, in light of the other actions and authorities described above.</P>
                <P>EPA has presented this impacts discussion consistent with Executive Order 12866. The potential impacts of this rulemaking and the potential for associated benefits and costs do not form any part of the basis of EPA's decision to propose the amendments in this notice. As described above, the amendments proposed today implement the plain language of RCRA and reflect what EPA believes was Congress' intent as to the scope of RCRA sections 3004(u) and (v) and 3008(h). EPA believes its regulations should accurately reflect what the statute authorizes and requires, as interpreted by EPA. EPA's estimate as to the potential impact of the amendments is not relevant either to what Congress intended in enacting these provisions or to whether EPA's regulations should accurately reflect that intent. In any event, even if potential impacts were relevant to today's proposal, EPA would proceed with the proposed amendments because, as explained above, EPA does not expect that the rule would result in any impacts.</P>
                <HD SOURCE="HD1">VI. State Implementation</HD>
                <HD SOURCE="HD2">A. Applicability of Rules in Authorized States</HD>
                <P>
                    Under section 3006 of RCRA, EPA may authorize qualified States to 
                    <PRTPAGE P="8604"/>
                    administer their own hazardous waste programs in lieu of the federal program within the State. Following authorization, EPA retains enforcement authority under section 3008, 3013, and 7003 of RCRA, although authorized States have primary enforcement responsibility. The standards and requirements for State authorization are found in 40 CFR part 271.
                </P>
                <P>
                    Prior to the enactment of the Hazardous and Solid Waste Amendments of 1984 (HSWA) and of the Hazardous Waste Electronic Manifest Establishment Act,
                    <SU>40</SU>
                    <FTREF/>
                     a State with final RCRA authorization administered its hazardous waste program entirely in lieu of EPA administering the federal program in that State. The federal requirements no longer applied in the authorized State, and EPA could not issue permits for any facilities in that State, since only the State was authorized to administer the program and issue RCRA permits. When new, more stringent federal requirements were promulgated, the State was obligated to adopt equivalent authorities within specified time frames. However, the new federal requirements did not take effect in an authorized State until the State adopted the federal requirements as State law.
                </P>
                <FTNT>
                    <P>
                        <SU>40</SU>
                         Public Law 112-195, October 5, 2012.
                    </P>
                </FTNT>
                <P>In contrast, with the adoption of RCRA section 3006(g), which was added by HSWA, new requirements and prohibitions imposed under the HSWA authority take effect in authorized States at the same time that they take effect in unauthorized States. EPA is directed by section 3006(g) to implement HSWA based requirements and prohibitions in authorized States until the State is granted authorization to do so. While States must still adopt HSWA related provisions as State law to retain final authorization, EPA implements the HSWA provisions in authorized States until the States do so.</P>
                <P>Authorized States are required to modify their programs when EPA promulgates federal requirements that are more stringent or broader in scope than existing federal requirements. RCRA section 3009 allows the States to impose standards more stringent than those in the federal program (see also § 271.1). If EPA promulgates a federal requirement that is less stringent than an existing requirement, authorized States may, but are not required to, adopt the requirement regardless of whether it is a HSWA or a non-HSWA requirement.</P>
                <HD SOURCE="HD2">B. Effect on State Authorization</HD>
                <P>The regulations proposed in this notice would be promulgated under the authority of HSWA. Thus, the standards would be applicable on the rule's effective date in all States and would be implemented by EPA until the States receive authorization.</P>
                <P>
                    Moreover, as stated in Section A above, authorized States are required to modify their programs when EPA promulgates federal regulations that are more stringent or broader in scope than the authorized State regulations. The revisions in this proposed rule are considered to be more stringent than the existing federal requirements.
                    <SU>41</SU>
                    <FTREF/>
                     Therefore, authorized States would be required to modify their programs to adopt regulations equivalent to the provisions contained in this proposed rule.
                </P>
                <FTNT>
                    <P>
                        <SU>41</SU>
                         As explained above, EPA does not expect this proposed rule to drive additional corrective action activity. However, it would amend the regulations in a way that makes them facially more stringent than the existing regulations. Because State regulations must be equivalent to and consistent with EPA regulations (RCRA section 3006(b); 40 CFR 271.3(a)), EPA believes that authorized State regulations will need to reflect the changes proposed today if those changes are made final, and EPA therefore considers the proposed revised rules to be more stringent than the existing rules.
                    </P>
                </FTNT>
                <P>As discussed earlier in this preamble, although the regulatory provisions would be new, these proposed amendments are consistent with EPA's longstanding interpretation of the RCRA statute. States with authorized RCRA programs already may have regulations similar to those in this proposed rule. These State regulations have not been assessed against the Federal regulations proposed today to determine whether they meet the tests for authorization. Thus, even after promulgation of final rules, a State would not be authorized to implement these regulations as RCRA requirements until State program modifications are submitted to EPA and approved, pursuant to § 271.21. Of course, States with existing regulations that are more stringent than or broader in scope than existing Federal regulations may continue to administer and enforce their regulations as a matter of State law. In implementing the HSWA requirements, EPA will work with the States under agreements to avoid duplication of effort.</P>
                <HD SOURCE="HD1">VII. Statutory and Executive Order Reviews</HD>
                <P>
                    Additional information about these statutes and Executive Orders can be found at 
                    <E T="03">https://www.epa.gov/laws-regulations/laws-and-executive-orders.</E>
                </P>
                <HD SOURCE="HD2">A. Executive Order 12866: Regulatory Planning and Review and Executive Order 13563: Improving Regulation and Regulatory Review</HD>
                <P>Under section 3(f)(4) of Executive Order 12866, this action is a significant regulatory action that was submitted to the Office of Management and Budget (OMB) for review. Any changes made in response to recommendations received as part of Executive Order 12866 review have been documented in the docket.</P>
                <P>
                    Additionally, EPA prepared an analysis of the potential costs and benefits associated with this action. This draft analysis, 
                    <E T="03">Economic Assessment for the Definition of Hazardous Waste Applicable to Corrective Action for Releases from Solid Waste Management Units (Economic Assessment),</E>
                     is available in the docket for this action.
                </P>
                <HD SOURCE="HD2">B. Paperwork Reduction Act (PRA)</HD>
                <P>
                    This action does not impose an information collection burden under the provisions of the 
                    <E T="03">Paperwork Reduction Act,</E>
                     44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                     Burden is defined at 5 CFR 1320.3(b).
                </P>
                <HD SOURCE="HD2">C. Regulatory Flexibility Act (RFA)</HD>
                <P>
                    I certify that this action will not have a significant economic impact on a substantial number of small entities under the RFA, 5 U.S.C. 601, 
                    <E T="03">et seq.</E>
                     EPA projects zero direct costs to regulated entities associated with the proposed rule. As explained in Section V, EPA does not expect that the rule would result in any impacts. While this analysis finds that this rule would not change costs for the regulated community, any unexpected costs would be indirect costs. For a given facility, the specific corrective measures required to address any statutory hazardous waste would depend on several facility-specific factors to be considered by EPA or authorized State permitting authorities, including the extent and magnitude of contamination. Because cleanups associated with any statutory hazardous waste would be implemented by either EPA or an authorized State permitting authority under the general corrective action standard in § 264.101, which requires corrective action be instituted “as necessary to protect human health or the environment,” relevant corrective action cost impacts that may be incurred at certain TSDFs are considered indirect.
                </P>
                <P>
                    Because the proposed rule is not expected to result in any additional costs (including direct costs), it is also not expected to result in a significant economic impact for a substantial 
                    <PRTPAGE P="8605"/>
                    number of small entities. The number of small entities within the universe are estimated within the 
                    <E T="03">Economic Assessment for the Definition of Hazardous Waste Applicable to Corrective Action at Solid Waste Management Units.</E>
                     We have therefore concluded that this action will not have a significant regulatory burden for all directly regulated small entities. However, EPA solicits comment on its conclusion that the proposed rule would not result in any additional costs, including to small entities, along with any data bearing on that conclusion. Details of our economic analysis are presented in the 
                    <E T="03">Economic Assessment for the Definition of Hazardous Waste Applicable to Corrective Action for Releases from Solid Waste Management Units,</E>
                     available in the public docket for this action.
                </P>
                <HD SOURCE="HD2">D. Unfunded Mandates Reform Act (UMRA)</HD>
                <P>This action does not contain any unfunded mandate as described in UMRA, 2 U.S.C. 1531-1538, and does not significantly or uniquely affect small governments. The action imposes no enforceable duty on any State, local or Tribal governments or the private sector.</P>
                <HD SOURCE="HD2">E. Executive Order 13132: Federalism</HD>
                <P>This action does not have federalism implications. It will not have substantial direct effects on the States, on the relationship between the national government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <HD SOURCE="HD2">F. Executive Order 13175: Consultation and Coordination With Indian Tribal Governments</HD>
                <P>This action does not have Tribal implications as specified in Executive Order 13175 because it does not have substantial direct effects on one or more Indian Tribes, on the relationship between the Federal Government and Indian Tribes, or on the distribution of power and responsibilities between the Federal Government and Indian Tribes. EPA does not expect that it would result in any adverse impacts on Tribal entities. Thus, Executive Order 13175 does not apply to this action.</P>
                <P>Consistent with the EPA Policy on Consultation with Indian Tribes, EPA intends to coordinate with Tribal officials.</P>
                <HD SOURCE="HD2">G. Executive Order 13045: Protection of Children From Environmental Health Risks and Safety Risks</HD>
                <P>Executive Order 13045 (62 FR 19885, April 23, 1997) directs federal agencies to include an evaluation of the health and safety effects of the planned regulation on children in federal health and safety standards and explain why the regulation is preferable to potentially effective and reasonably feasible alternatives. This action is not subject to Executive Order 13045 because it is not deemed to be a significant regulatory action under section 3(f)(1) of Executive Order 12866, and because EPA does not believe the environmental health or safety risks addressed by this action present a disproportionate risk to children. Because the proposed rule is not expected to change the frequency, scale, or location of corrective action, EPA does not expect the proposed rule to result in, or reduce, disproportionate adverse impacts on children's health.</P>
                <P>However, EPA's Policy on Children's Health applies to this action. Information on how the Policy was applied is available under “Children's Environmental Health” in the Economic Assessment, which is included in the docket for this rulemaking.</P>
                <HD SOURCE="HD2">H. Executive Order 13211: Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution or Use</HD>
                <P>This action is not a “significant energy action” because it is not likely to have a significant adverse effect on the supply, distribution, or use of energy. This action proposes to amend the regulatory definition of hazardous waste applicable to corrective action to address releases from solid waste management units at RCRA-permitted treatment, storage, and disposal facilities and make related conforming amendments, and thus, does not involve the supply, distribution, or use of energy.</P>
                <HD SOURCE="HD2">I. National Technology Transfer and Advancement Act (NTTAA)</HD>
                <P>This rulemaking does not involve technical standards.</P>
                <HD SOURCE="HD2">J. Executive Order 12898: Federal Actions To Address Environmental Justice in Minority Populations and Low-Income Populations and Executive Order 14096: Revitalizing Our Nation's Commitment to Environmental Justice for All</HD>
                <P>
                    EPA believes that the human health or environmental conditions that exist prior to this action result in or have the potential to result in disproportionate and adverse human health or environmental effects on communities with environmental justice concerns.
                    <SU>42</SU>
                    <FTREF/>
                     A screening analysis of six existing permitted facilities was conducted and revealed that two facilities appear to be sited such that EJ indices from EPA's EJScreen generally exceed the 70th percentile on both a State and national basis. This limited data and analysis indicate that conditions prior to a potential action could result in disproportionate and adverse human health or environmental effects to communities with environmental justice concerns.
                </P>
                <FTNT>
                    <P>
                        <SU>42</SU>
                         Based on data from EPA's RCRAInfo database, 1,740 treatment, storage, and disposal facilities have RCRA permits as of February 2023. The count of 1,740 includes all TSDFs with at least one permitted treatment, storage, or disposal unit. See the Economic Assessment for this rule, available in the docket, for a more detailed discussion of the universe of permitted facilities that would be subject to this rulemaking.
                    </P>
                </FTNT>
                <P>EPA believes that this action is not likely to change existing disproportionate and adverse effects on people in communities with environmental justice concerns. As described in Chapter 3 of the Economic Assessment, EPA does not expect the proposed rule to change the frequency or scale of corrective action; further, EPA does not expect the proposed rule to alter the siting of RCRA treatment, storage, and disposal facilities in any way. Given that the ability to address substances that are not regulatory hazardous waste has been available to program implementers in the past, EPA has no reason to expect that those substances, in general, would be addressed through corrective action more frequently in the future as a result of this proposed rule.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in Parts 260, 261, and 270</HD>
                    <P>Environmental protection, Hazardous waste. </P>
                </LSTSUB>
                <SIG>
                    <NAME>Michael S. Regan,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
                <P>For the reasons set out in the preamble, the Environmental Protection Agency proposes to amend 40 CFR parts 260, 261, and 270 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 260—HAZARDOUS WASTE MANAGEMENT SYSTEM: GENERAL</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 260 is revised to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>42 U.S.C. 6903(5), 6905, 6912(a), 6921-6927, 6930, 6934, 6935, 6937, 6938, 6939, and 6974.</P>
                </AUTH>
                <AMDPAR>
                    2. Section 260.10 is amended by revising the definition “
                    <E T="03">Hazardous waste”</E>
                     to read as follows:
                </AMDPAR>
                <SECTION>
                    <PRTPAGE P="8606"/>
                    <SECTNO>§ 260.10 </SECTNO>
                    <SUBJECT>Definitions.</SUBJECT>
                    <STARS/>
                    <P>
                        <E T="03">Hazardous waste</E>
                         means a hazardous waste as defined in § 261.3 of this chapter, except that, for purposes of §§ 264.101 and 270.14(d), “hazardous waste” means a waste that is subject to the requirements of RCRA section 3004(u) and (v) as provided in 40 CFR 261.1(b)(2).
                    </P>
                    <STARS/>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 261—IDENTIFICATION AND LISTING OF HAZARDOUS WASTE</HD>
                </PART>
                <AMDPAR>3. The authority citation for part 261 is revised to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 42 U.S.C 6903(5), 6905, 6912(a), 6921, 6922, 6924(u), 6924(v), 6924(y), 6928(h), and 6938.</P>
                </AUTH>
                <AMDPAR>4. Section 261.1 is amended by revising the first sentence of paragraph (b)(2) and paragraphs (b)(2)(i) and (ii) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 261.1 </SECTNO>
                    <SUBJECT>Purpose and scope.</SUBJECT>
                    <STARS/>
                    <P>(b)(2) This part identifies only some of the materials which are solid wastes and hazardous wastes under sections 3004(u) and (v), 3007, 3008(h), 3013, and 7003 of RCRA. * * *</P>
                    <P>(i) In the case of sections 3007 and 3013, and in the case of activities, such as investigation and analysis, conducted to determine the need for and the extent of remediation necessary under sections 3004(u) and (v) and 3008(h), EPA has reason to believe that the material may be a solid waste within the meaning of section 1004(27) of RCRA and a hazardous waste within the meaning of section 1004(5) of RCRA; or</P>
                    <P>(ii) in the case of section 7003, and in the case of activities conducted for purposes of remediation under sections 3004(u) and (v) and 3008(h), including remediation conducted as an interim measure, the statutory elements are established.</P>
                    <STARS/>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 270—EPA ADMINISTERED PERMIT PROGRAMS: THE HAZARDOUS WASTE PERMIT PROGRAM</HD>
                </PART>
                <AMDPAR>5. The authority citation for part 270 is revised to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 42 U.S.C 6903(5), 6905, 6912, 6924, 6925, 6927, 6939, and 6974.</P>
                </AUTH>
                <AMDPAR>
                    6. Section 270.2 is amended by revising the definition of “
                    <E T="03">Hazardous waste”</E>
                     to read as follows:
                </AMDPAR>
                <SECTION>
                    <SECTNO>§ 270.2 </SECTNO>
                    <SUBJECT>Definitions.</SUBJECT>
                    <STARS/>
                    <P>
                        <E T="03">Hazardous waste</E>
                         means a hazardous waste as defined in 40 CFR 261.3 except that, for purposes of § 270.14(d), “hazardous waste” means a waste that is subject to the requirements of RCRA section 3004(u) and (v) as provided in 40 CFR 261.1(b)(2).
                    </P>
                    <STARS/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02328 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Parts 261 and 271</CFR>
                <DEPDOC>[EPA-HQ-OLEM-2023-0278; FRL-9248-01-OLEM]</DEPDOC>
                <RIN>RIN 2050-AH26</RIN>
                <SUBJECT>Listing of Specific PFAS as Hazardous Constituents</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA)</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA or the Agency) is proposing to amend its regulation under the Resource Conservation and Recovery Act (RCRA) by adding nine specific per-and polyfluoroalkyl substances (PFAS), their salts, and their structural isomers, to its list of hazardous constituents. These nine PFAS are perfluorooctanoic acid (PFOA), perfluorooctanesulfonic acid (PFOS), perfluorobutanesulfonic acid (PFBS), hexafluoropropylene oxide-dimer acid (HFPO-DA or GenX), perfluorononanoic acid (PFNA), perfluorohexanesulfonic acid (PFHxS), perfluorodecanoic acid (PFDA), perfluorohexanoic acid (PFHxA), and perfluorobutanoic acid (PFBA). EPA's criteria for listing substances as hazardous constituents under RCRA require that they have been shown in scientific studies to have toxic, carcinogenic, mutagenic, or teratogenic effects on humans or other life forms. EPA reviewed and evaluated key toxicity and epidemiological studies and assessments for the nine PFAS to determine whether the available data for these PFAS meet the Agency's criteria for listing substances as hazardous constituents under RCRA. Based on EPA's evaluation, the above nine PFAS, their salts, and their structural isomers meet the criteria for being listed as RCRA hazardous constituents. As a result of this proposed rule, if finalized, when corrective action requirements are imposed at a facility, these PFAS would be among the hazardous constituents expressly identified for consideration in RCRA facility assessments and, where necessary, further investigation and cleanup through the RCRA corrective action process at RCRA treatment, storage, and disposal facilities.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before April 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, identified by Docket ID No. EPA-HQ-OLEM-2023-0278, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal: https://www.regulations.gov (our preferred method).</E>
                         Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Environmental Protection Agency, EPA Docket Center, OLEM Docket, Mail Code 28221T, 1200 Pennsylvania Avenue NW, Washington, DC 20460.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         EPA Docket Center, WJC West Building, Room 3334, 1301 Constitution Avenue NW, Washington, DC 20004. The Docket Center's hours of operations are 8:30 a.m.-4:30 p.m., Monday-Friday (except Federal Holidays).
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the Docket ID No. for this rulemaking. Comments received may be posted without change to 
                        <E T="03">https://www.regulations.gov/,</E>
                         including any personal information provided. For detailed instructions on sending comments and additional information on the rulemaking process, see the “Public Participation” heading of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this document. For further information on EPA Docket Center services and the current status, please visit us online at 
                        <E T="03">https://www.epa.gov/dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Narendra Chaudhari, Office of Resource Conservation and Recovery (5304T), Environmental Protection Agency, 1200 Pennsylvania Avenue NW, Washington, DC 20460; telephone number 202-566-0495; email address: 
                        <E T="03">Chaudhari.narendra@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Public Participation</FP>
                    <FP SOURCE="FP1-2">A. Written Comments</FP>
                    <FP SOURCE="FP-2">II. General Information</FP>
                    <FP SOURCE="FP1-2">A. Does this action apply to me?</FP>
                    <FP SOURCE="FP1-2">B. What action is the Agency taking?</FP>
                    <FP SOURCE="FP1-2">C. Why is the Agency taking this action?</FP>
                    <FP SOURCE="FP1-2">D. Impacts of the Proposed Rule</FP>
                    <FP SOURCE="FP1-2">E. What are the incremental costs and benefits of this action?</FP>
                    <FP SOURCE="FP-2">III. Legal Authority</FP>
                    <FP SOURCE="FP1-2">A. What is the Agency's authority for taking this action?</FP>
                    <FP SOURCE="FP1-2">B. RCRA Sections 3001 and 3004(u) Preclude Consideration of Cost in Identifying Hazardous Constituents</FP>
                    <FP SOURCE="FP-2">IV. Background</FP>
                    <FP SOURCE="FP1-2">A. What are PFAS?</FP>
                    <FP SOURCE="FP1-2">
                        B. What has been learned from PFAS toxicity studies?
                        <PRTPAGE P="8607"/>
                    </FP>
                    <FP SOURCE="FP-2">V. Review of the Available Toxicity and Health Effects Information for PFAS</FP>
                    <FP SOURCE="FP1-2">A. PFAS Identified To Have Sufficient Information To Be Evaluated for Appendix VIII Listing Criteria</FP>
                    <FP SOURCE="FP1-2">B. Summary of Toxicity and Health Effects Information for the Nine PFAS</FP>
                    <FP SOURCE="FP1-2">C. EPA's Proposed Conclusions on Whether the Nine PFAS, Their Salts, and Their Structural Isomers Meet the Criteria for Listing on Appendix VIII</FP>
                    <FP SOURCE="FP-2">VI. State Authorization</FP>
                    <FP SOURCE="FP1-2">A. Applicability of the Rule in Authorized States</FP>
                    <FP SOURCE="FP1-2">B. Effect on State Authorization</FP>
                    <FP SOURCE="FP-2">VII. Statutory and Executive Order Reviews</FP>
                    <FP SOURCE="FP1-2">A. Executive Order 12866: Regulatory Planning and Review and Executive Order 14094: Modernizing Regulatory Review</FP>
                    <FP SOURCE="FP1-2">B. Paperwork Reduction Act (PRA)</FP>
                    <FP SOURCE="FP1-2">C. Regulatory Flexibility Act (RFA)</FP>
                    <FP SOURCE="FP1-2">D. Unfunded Mandates Reform Act (UMRA)</FP>
                    <FP SOURCE="FP1-2">E. Executive Order 13132: Federalism</FP>
                    <FP SOURCE="FP1-2">F. Executive Order 13175: Consultation and Coordination With Indian Tribal Governments</FP>
                    <FP SOURCE="FP1-2">G. Executive Order 13045: Protection of Children From Environmental Health Risks and Safety Risks</FP>
                    <FP SOURCE="FP1-2">H. Executive Order 13211: Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use</FP>
                    <FP SOURCE="FP1-2">I. National Technology Transfer and Advancement Act (NTTAA)</FP>
                    <FP SOURCE="FP1-2">J. Executive Order 12898: Federal Actions To Address Environmental Justice in Minority Populations and Low-Income Populations; Executive Order 14096: Revitalizing Our Nation's Commitment to Environmental Justice for All</FP>
                    <FP SOURCE="FP-2">VIII. References</FP>
                </EXTRACT>
                <HD SOURCE="HD1">List of Abbreviations and Acronyms</HD>
                <P>The following list is for reference only and is not exhaustive:</P>
                <EXTRACT>
                    <FP SOURCE="FP-1">AFFF Aqueous film-forming foam</FP>
                    <FP SOURCE="FP-1">ATSDR Agency for Toxic Substances and Disease Registry</FP>
                    <FP SOURCE="FP-1">CDC Centers for Disease Control and Prevention</FP>
                    <FP SOURCE="FP-1">CERCLA Comprehensive Environmental Response, Compensation, and Liability Act</FP>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">ECF Electrochemical fluorination</FP>
                    <FP SOURCE="FP-1">EJ Environmental justice</FP>
                    <FP SOURCE="FP-1">EPA Environmental Protection Agency</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">GenX Processing aid technology that includes Hexafluoropropylene Oxide-Dimer acid and its ammonium salt</FP>
                    <FP SOURCE="FP-1">HFPO-DA Hexafluoropropylene Oxide-Dimer acid</FP>
                    <FP SOURCE="FP-1">HSWA Hazardous and Solid Waste Amendments of 1984</FP>
                    <FP SOURCE="FP-1">mg/kg milligram per kilogram</FP>
                    <FP SOURCE="FP-1">mg/kg/day milligram per kilogram per day</FP>
                    <FP SOURCE="FP-1">NAICS North American Industrial Classification System</FP>
                    <FP SOURCE="FP-1">OMB Office of Management and Budget</FP>
                    <FP SOURCE="FP-1">PBI Proprietary Business Information</FP>
                    <FP SOURCE="FP-1">PFAS Per- and polyfluoroalkyl substances</FP>
                    <FP SOURCE="FP-1">PFBA Perfluorobutanoic acid</FP>
                    <FP SOURCE="FP-1">PFBS Perfluorobutanesulfonic acid</FP>
                    <FP SOURCE="FP-1">PFDA Perfluorodecanoic acid</FP>
                    <FP SOURCE="FP-1">PFHxA Perfluorohexanoic acid</FP>
                    <FP SOURCE="FP-1">PFHxS Perfluorohexanesulfonic acid</FP>
                    <FP SOURCE="FP-1">PFNA Perfluorononanoic acid</FP>
                    <FP SOURCE="FP-1">PFOA Perfluorooctanoic acid</FP>
                    <FP SOURCE="FP-1">PFOS Perfluorooctanesulfonic acid</FP>
                    <FP SOURCE="FP-1">RCRA Resource Conservation and Recovery Act</FP>
                    <FP SOURCE="FP-1">RFA Regulatory Flexibility Act</FP>
                    <FP SOURCE="FP-1">RfD Reference dose</FP>
                    <FP SOURCE="FP-1">SWMU Solid Waste Management Unit</FP>
                    <FP SOURCE="FP-1">TSDFs Treatment, storage, and disposal facilities</FP>
                    <FP SOURCE="FP-1">UMRA Unfunded Mandates Reform Act</FP>
                    <FP SOURCE="FP-1">U.S. United States</FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Public Participation</HD>
                <HD SOURCE="HD2">A. Written Comments</HD>
                <P>
                    Submit your comments, identified by Docket ID No. EPA-HQ-OLEM-2023-0278, at 
                    <E T="03">https://www.regulations.gov</E>
                     (our preferred method), or the other methods identified in the 
                    <E T="02">ADDRESSES</E>
                     section. Once submitted, comments cannot be edited or removed from the docket. EPA may publish any comment received to its public docket. Do not submit to EPA's docket at 
                    <E T="03">https://www.regulations.gov</E>
                     any information you consider to be Proprietary Business Information (PBI) or other information whose disclosure is restricted by statute. Multimedia submissions (audio, video, etc.) must be accompanied by a written comment. The written comment is considered the official comment and should include discussion of all points you wish to make. EPA will generally not consider comments or comment contents located outside of the primary submission (
                    <E T="03">i.e.,</E>
                     on the web, cloud, or other file sharing system). For additional submission methods, the full EPA public comment policy, information about PBI or multimedia submissions, and general guidance on making effective comments, please visit 
                    <E T="03">https://www.epa.gov/dockets/commenting-epa-dockets.</E>
                </P>
                <P>
                    For further information and updates on EPA Docket Center services, please visit us online at 
                    <E T="03">https://www.epa.gov/dockets.</E>
                </P>
                <P>EPA continues to monitor information carefully and continuously from the Centers for Disease Control and Prevention (CDC), local area health departments, and our Federal partners so that we can respond rapidly as conditions change regarding COVID-19.</P>
                <HD SOURCE="HD1">II. General Information</HD>
                <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                <P>The purpose of this proposed rulemaking is to add nine PFAS, their salts, and their structural isomers, to the list of hazardous constituents in 40 CFR part 261 Appendix VIII (Appendix VIII). Entities potentially affected by this action include hazardous waste treatment, storage, and disposal facilities (TSDFs) with solid waste management units (SWMUs) that have released or could release any of the PFAS proposed to be listed as RCRA hazardous constituents. EPA has identified 1,740 such facilities, which could be subject to additional corrective action requirements (pursuant to RCRA section 3004(u) and (v)) to address releases not already subject to corrective action pursuant to EPA's corrective action regulations.</P>
                <P>
                    The following list of North American Industrial Classification System (NAICS) codes is not intended to be exhaustive, but rather provides a guide for readers to determine whether this action may affect them. For further details about the potentially affected universe of facilities, refer to Section 3.2 of the draft 
                    <E T="03">Economic Assessment of the Potential Costs, Benefits, and Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents</E>
                     (Ref. 41), which can be found in the public docket for this action. Potentially affected entities may include:
                </P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="xs50,r100,12,12">
                    <TTITLE>Table II-1—Potentially Affected Entities</TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            NAICS
                            <LI>(3-digits)</LI>
                        </CHED>
                        <CHED H="1">NAICS description</CHED>
                        <CHED H="1">
                            Universe of
                            <LI>facilities</LI>
                        </CHED>
                        <CHED H="1">
                            Facilities with higher
                            <LI>likelihood</LI>
                            <LI>of handling</LI>
                            <LI>PFAS</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">111</ENT>
                        <ENT>Crop Production</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">115</ENT>
                        <ENT>Support Activities for Agriculture and Forestry</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">211</ENT>
                        <ENT>Oil and Gas Extraction</ENT>
                        <ENT>2</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">213</ENT>
                        <ENT>Support Activities for Mining</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8608"/>
                        <ENT I="01">221</ENT>
                        <ENT>Utilities</ENT>
                        <ENT>25</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">233</ENT>
                        <ENT>Building, Developing, and General Contracting</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">238</ENT>
                        <ENT>Specialty Trade Contractors</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">311</ENT>
                        <ENT>Food Manufacturing</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">312</ENT>
                        <ENT>Beverage and Tobacco Product Manufacturing</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">313</ENT>
                        <ENT>Textile Mills</ENT>
                        <ENT>4</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">321</ENT>
                        <ENT>Wood Product Manufacturing</ENT>
                        <ENT>52</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">322</ENT>
                        <ENT>Paper Manufacturing</ENT>
                        <ENT>3</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">323</ENT>
                        <ENT>Printing and Related Support Activities</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">324</ENT>
                        <ENT>Petroleum and Coal Products Manufacturing</ENT>
                        <ENT>79</ENT>
                        <ENT>76</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">325</ENT>
                        <ENT>Chemical Manufacturing</ENT>
                        <ENT>335</ENT>
                        <ENT>278</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">326</ENT>
                        <ENT>Plastics and Rubber Products Manufacturing</ENT>
                        <ENT>14</ENT>
                        <ENT>9</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">327</ENT>
                        <ENT>Nonmetallic Mineral Product Manufacturing</ENT>
                        <ENT>23</ENT>
                        <ENT>9</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">331</ENT>
                        <ENT>Primary Metal Manufacturing</ENT>
                        <ENT>68</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">332</ENT>
                        <ENT>Fabricated Metal Product Manufacturing</ENT>
                        <ENT>68</ENT>
                        <ENT>28</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">333</ENT>
                        <ENT>Machinery Manufacturing</ENT>
                        <ENT>20</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">334</ENT>
                        <ENT>Computer and Electronic Product Manufacturing</ENT>
                        <ENT>46</ENT>
                        <ENT>19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">335</ENT>
                        <ENT>Electrical Equipment, Appliance, and Component Manufacturing</ENT>
                        <ENT>12</ENT>
                        <ENT>3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">336</ENT>
                        <ENT>Transportation Equipment Manufacturing</ENT>
                        <ENT>64</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">337</ENT>
                        <ENT>Furniture and Related Product Manufacturing</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">339</ENT>
                        <ENT>Miscellaneous Manufacturing</ENT>
                        <ENT>14</ENT>
                        <ENT>2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">422</ENT>
                        <ENT>Wholesale Trade, Nondurable Goods</ENT>
                        <ENT>6</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">423</ENT>
                        <ENT>Merchant Wholesalers, Durable Goods</ENT>
                        <ENT>14</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">424</ENT>
                        <ENT>Merchant Wholesalers, Nondurable Goods</ENT>
                        <ENT>38</ENT>
                        <ENT>38</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">447</ENT>
                        <ENT>Gasoline Stations</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">454</ENT>
                        <ENT>Non-store Retailers</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">481</ENT>
                        <ENT>Air Transportation</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">482</ENT>
                        <ENT>Rail Transportation</ENT>
                        <ENT>4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">484</ENT>
                        <ENT>Truck Transportation</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">486</ENT>
                        <ENT>Pipeline Transportation</ENT>
                        <ENT>4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">488</ENT>
                        <ENT>Support Activities for Transportation</ENT>
                        <ENT>11</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">493</ENT>
                        <ENT>Warehousing and Storage</ENT>
                        <ENT>22</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">519</ENT>
                        <ENT>Other Information Services</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">525</ENT>
                        <ENT>Funds, Trusts, and Other Financial Vehicles</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">531</ENT>
                        <ENT>Real Estate</ENT>
                        <ENT>12</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">532</ENT>
                        <ENT>Rental and Leasing Services</ENT>
                        <ENT>4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">541</ENT>
                        <ENT>Professional, Scientific, and Technical Services</ENT>
                        <ENT>39</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">551</ENT>
                        <ENT>Management of Companies and Enterprises</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">561</ENT>
                        <ENT>Administrative and Support Services</ENT>
                        <ENT>22</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">562</ENT>
                        <ENT>Waste Management and Remediation Services</ENT>
                        <ENT>461</ENT>
                        <ENT>359</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">611</ENT>
                        <ENT>Educational Services</ENT>
                        <ENT>31</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">621</ENT>
                        <ENT>Ambulatory Health Care Services</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">622</ENT>
                        <ENT>Hospitals</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">811</ENT>
                        <ENT>Repair and Maintenance</ENT>
                        <ENT>7</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">813</ENT>
                        <ENT>Religious, Grantmaking, Civic, Professional, and Similar Organizations</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">921</ENT>
                        <ENT>Executive, Legislative, and Other General Government Support</ENT>
                        <ENT>13</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">922</ENT>
                        <ENT>Justice, Public Order, and Safety Activities</ENT>
                        <ENT>2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">924</ENT>
                        <ENT>Administration of Environmental Quality Programs</ENT>
                        <ENT>9</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">925</ENT>
                        <ENT>Administration of Housing Programs, Urban Planning, and Community Development</ENT>
                        <ENT>1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">926</ENT>
                        <ENT>Administration of Economic Programs</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">927</ENT>
                        <ENT>Space Research and Technology</ENT>
                        <ENT>5</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">928</ENT>
                        <ENT>National Security and International Affairs</ENT>
                        <ENT>142</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW RUL="n,n,s">
                        <ENT I="01">Missing</ENT>
                        <ENT/>
                        <ENT>27</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT/>
                        <ENT>1,740</ENT>
                        <ENT>831</ENT>
                    </ROW>
                    <TNOTE>
                        <E T="02">Notes:</E>
                         1. This proposed rule only lists specific PFAS as hazardous constituents in 40 CFR part 261, Appendix VIII. EPA notes that listing these PFAS as RCRA hazardous constituents does not make them, or the wastes containing them, RCRA hazardous wastes.
                    </TNOTE>
                </GPOTABLE>
                <PRTPAGE P="8609"/>
                <HD SOURCE="HD2">B. What action is the Agency taking?</HD>
                <P>
                    This action is proposing to amend EPA's regulations under RCRA by listing the following nine PFAS (names given for acid forms below), their salts, and their structural isomers 
                    <SU>1</SU>
                    <FTREF/>
                     as hazardous constituents in 40 CFR part 261 Appendix VIII:
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         All references to PFOA, PFOS, PFBS, HFPO-DA (or GenX), PFNA, PFHxS, PFDA, PFHxA, and PFBA or to all nine PFAS in this notice are meant to include their salts and their linear and branched structural isomers, except where the notice expressly distinguishes the different forms. The CASRN for the linear acid version is given for reference. Linear and branched structural isomers maintain the carboxylic acid and sulfonic acid functional groups, respectively, but have different arrangements of the carbon atoms in the fluorinated carbon chain. The reference to HFPO-DA only applies to the specific structural isomer noted, including both enantiomers.
                    </P>
                </FTNT>
                <EXTRACT>
                    <P>
                        <E T="03">1. Perfluorooctanoic acid</E>
                         (PFOA; CASRN 335-67-1). PFOA is an eight-carbon molecule with seven fully fluorinated carbon atoms and one carboxylic acid functional group. It has been used as a processing aid to produce fluoropolymers and has been found in cleaning agents, waxes, aqueous film-forming foam (AFFF), and other products.
                    </P>
                    <P>
                        <E T="03">2. Perfluorooctanesulfonic acid</E>
                         (PFOS; CASRN 1763-23-1). PFOS is a fully fluorinated eight-carbon molecule with one sulfonic acid functional group. It has been used in AFFF, in surface treatments of textiles to provide oil and water resistance, in metal plating, and other uses and industries.
                    </P>
                    <P>
                        <E T="03">3. Perfluorobutanesulfonic acid</E>
                         (PFBS; CASRN 375-73-5). PFBS is a fully fluorinated four-carbon molecule with one sulfonic acid group. It has been used as a replacement for PFOS and has been used in the manufacture of paints and cleaning agents, metal plating, AFFF, to provide oil and water resistance, and other uses and industries.
                    </P>
                    <P>
                        <E T="03">4. Hexafluoropropylene oxide-dimer acid</E>
                         (HFPO-DA or GenX; CASRN 13252-13-6). HFPO-DA is a six-carbon molecule consisting of five fully fluorinated carbon atoms, one ether functional group, and one carboxylic acid functional group. HFPO-DA is a chemical associated with GenX processing aid technology used to make fluoropolymers without the use of PFOA.
                    </P>
                    <P>
                        <E T="03">5. Perfluorononanoic acid</E>
                         (PFNA; CASRN 375-95-1). PFNA is a nine-carbon molecule with eight fully fluorinated carbon atoms and one carboxylic acid functional group. It has been used as a processing aid to produce fluoropolymers and has been used or found in metal plating, cleaning agents, waxes, AFFF, energetic materials, and other products.
                    </P>
                    <P>
                        <E T="03">6. Perfluorohexanesulfonic acid</E>
                         (PFHxS; CASRN 355-46-4). PFHxS is a fully fluorinated six-carbon molecule with one sulfonic acid functional group. It has been used in AFFF, in surface treatments of textiles to provide oil and water resistance, in metal plating, and other uses and industries.
                    </P>
                    <P>
                        <E T="03">7. Perfluorodecanoic acid</E>
                         (PFDA; CASRN 335-76-2). PFDA is a ten-carbon molecule with nine fully fluorinated carbon atoms and a carboxylic acid functional group. It has been used as a processing aid to produce fluoropolymers and has been used or found in metal plating solutions, cleaning agents, waxes, AFFF, and other products.
                    </P>
                    <P>
                        <E T="03">8. Perfluorohexanoic acid</E>
                         (PFHxA; CASRN 307-24-4). PFHxA is a six-carbon molecule with five fully fluorinated carbon atoms and a carboxylic acid functional group. It has been used or found in metal plating solutions, cleaning agents, waxes, AFFF, and other products.
                    </P>
                    <P>
                        <E T="03">9. Perfluorobutanoic acid</E>
                         (PFBA; CASRN 375-22-4). PFBA is a four-carbon molecule with three fully fluorinated carbon atoms and one carboxylic acid functional group. It has been used or found in metal plating, cleaning agents, waxes, AFFF, energetic materials, and other products.
                    </P>
                </EXTRACT>
                <P>In addition, if finalized, this action would add this listing action, as it would apply for corrective action purposes, to Table 1 in 40 CFR 271.1. Table 1 in 40 CFR 271.1 identifies the Federal program requirements that are promulgated pursuant to HSWA and take effect in all States, regardless of their authorization status.</P>
                <HD SOURCE="HD2">C. Why is the Agency taking this action?</HD>
                <P>EPA is proposing to list the nine PFAS, their salts, and their structural isomers as RCRA hazardous constituents because animal and epidemiological studies and assessments have shown that exposure to these PFAS have toxic and adverse effects in animals, humans, or both. The toxic and adverse effects include reproductive effects, developmental effects, increased risk of some cancers, reduced immune system response, and increased cholesterol levels (Refs. 1 and 2).</P>
                <P>
                    In addition, EPA has received three petitions requesting that the Agency take regulatory actions on PFAS under RCRA. The petitions were submitted by Public Employees for Environmental Responsibility (PEER), Environmental Law Clinic of University of California, Berkeley (UC Berkeley), and the Governor of New Mexico. PEER's petition, submitted on September 19, 2019, requested that EPA develop regulations for listing wastes containing PFAS (long-chain and short chain) as hazardous wastes under Subtitle C of RCRA to ensure the safe management and disposal of these wastes (Ref. 3). UC Berkeley's petition, submitted on January 15, 2020, on behalf of six community and environmental advocacy groups from six different states (California, Alaska, North Carolina, Pennsylvania, Michigan, and Colorado), requested that EPA promulgate regulations listing wastes containing PFOA, PFOS, GenX chemicals (including HFPO-DA and its ammonium salt), or any combination of these, as hazardous wastes and that the RCRA hazardous waste listings for PFOA and PFOS wastes extend to cover the full chemical subclass of each (long-chain perfluoroalkyl carboxylates and sulfonates) (Ref. 4). The Governor of New Mexico's petition, submitted on June 23, 2021, incorporated the above two petitions by reference and requested a timely listing of PFAS, as a class of chemicals, as hazardous wastes under the RCRA Subtitle C regulations, or in the alternative, a listing of individual PFAS chemicals as hazardous wastes under the regulations (Ref. 5). EPA acted upon the Governor of New Mexico's petition with its October 26, 2021 letter (Ref. 6). EPA indicated in that letter that it would be initiating the rulemaking process for two rulemakings. This proposal, along with EPA's proposal titled 
                    <E T="03">Definition of Hazardous Waste Applicable to Corrective Action for Releases from Solid Waste Management Units,</E>
                     constitute initiation of those rulemakings.
                </P>
                <P>EPA evaluated the information in the above three petitions in addition to the toxicity and health effects data available for PFAS and determined that the existing data for PFAS supports listing the nine PFAS, their salts, and their structural isomers at issue in this action as RCRA hazardous constituents in 40 CFR part 261 Appendix VIII (see section V for additional information).</P>
                <P>
                    A hazardous constituent listing is a step toward a potential hazardous waste listing. To list a waste as a RCRA hazardous waste under 40 CFR 261.11(a)(3), the Agency must show that the waste contains a hazardous constituent listed on Appendix VIII and determine that it is capable of posing a substantial hazard. This determination requires EPA to collect and carefully consider information on the eleven regulatory factors specified in 40 CFR 261.11(a)(3).
                    <SU>2</SU>
                    <FTREF/>
                     If finalized, this hazardous constituent listing would form part of the basis for any future action the Agency may take to list these substances as a hazardous waste. EPA will continue to evaluate available data to determine whether a future regulatory action to list certain PFAS, or waste containing such PFAS, as regulatory hazardous waste is appropriate. In the meantime, based on the toxicity and human health effects data available and 
                    <PRTPAGE P="8610"/>
                    evaluated by EPA for each of the nine PFAS, EPA is moving forward with this regulatory action under RCRA to add the nine PFAS, their salts, and their structural isomers, as hazardous constituents in 40 CFR part 261 Appendix VIII.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The eleven factors to be considered are: constituent toxicity, concentration, migration potential, persistence, degradation product potential, bioaccumulation potential, plausible management scenarios, waste quantity, damage cases, coverage by other regulatory programs, and other factors as may be appropriate.
                    </P>
                </FTNT>
                <P>Finally, EPA is proposing to designate these PFAS as hazardous constituents so that when corrective action requirements are imposed by program implementers these PFAS would be among the constituents expressly identified for consideration in RCRA facility assessments, and where necessary, further investigation and cleanup through the RCRA corrective action process at RCRA TSDFs.</P>
                <HD SOURCE="HD2">D. Impacts of the Proposed Rule</HD>
                <P>EPA is proposing to list nine PFAS, their salts, and their structural isomers, as RCRA hazardous constituents in 40 CFR part 261 Appendix VIII. The Appendix VIII list of hazardous constituents does not by itself impose regulatory requirements. Rather, references to hazardous constituents are found in various sections of the Federal hazardous waste regulations in Parts 261, 264, 265, 268, and 270.</P>
                <P>
                    The principal impacts of this rule will be on the RCRA Corrective Action Program. EPA expects that the proposed rule, combined with the Agency's increased attention to addressing risks associated with PFAS,
                    <SU>3</SU>
                    <FTREF/>
                     would facilitate and likely result in additional corrective action to address releases of specific PFAS listed as RCRA hazardous constituents. RCRA section 3004(u) requires that any permit issued to a TSDF after November 8, 1984 require corrective action for all releases of hazardous waste or hazardous constituents from solid waste management units at the facility. In the 1990 Subpart S proposed corrective action rule (see 55 FR 30798; July 27, 1990), EPA stated its view that the use of the phrase “hazardous waste or constituents” in section 3004(u) indicates that Congress was particularly concerned that the Agency use its corrective action authority to address hazardous constituents and stated that the term “hazardous constituents” in section 3004(u) means those constituents found in Appendix VIII.
                    <SU>4</SU>
                    <FTREF/>
                     Thus, hazardous constituents listed on Appendix VIII are assessed for and addressed as part of the corrective action process as necessary to protect human health and the environment. As a result of this proposed rule, nine PFAS, their salts, and their structural isomers would be among the hazardous constituents expressly identified for consideration in RCRA facility assessments and, where necessary, further investigation and cleanup through the corrective action process.
                    <SU>5</SU>
                    <FTREF/>
                     Additional discussion of this topic can be found in the draft Economic Assessment (Ref. 41). Applicability of the rule in authorized states and effect on state authorization are discussed in Section VI of this preamble.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         For example, see, PFAS Strategic Roadmap, EPA's Commitment to Action 2021-2024, 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/pfas-roadmap_final-508.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         EPA, in addition, proposed to include constituents appearing in 40 CFR part 264 Appendix IX as hazardous constituents subject to corrective action. 55 FR at 30809.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         A facility-specific administrative record would still be needed to support corrective action measures imposed on the basis of protection of human health or the environment.
                    </P>
                </FTNT>
                <P>While various RCRA regulatory provisions, unrelated to corrective action, reference hazardous constituents, EPA expects that any impacts from those references would be negligible, as EPA expects that the processes and procedures currently in place to meet the requirements of these regulations would likely address PFAS as well as other constituents already on Appendix VIII. Furthermore, there are also a few references to hazardous constituents or Appendix VIII in other, non-RCRA, EPA regulations; EPA also believes the impacts from these regulations would be negligible.</P>
                <P>The scope of this proposal is limited. Listing these PFAS as RCRA hazardous constituents does not make them, or the wastes containing them, RCRA hazardous wastes. Additionally, only facilities that are hazardous waste TSDFs are subject to RCRA corrective action. 42 U.S.C. 3004(u), (v). Therefore, EPA anticipates that, for example, a facility such as a publicly owned treatment works (POTW), would not be potentially affected by the RCRA corrective action requirements unless the facility is a hazardous waste TSDF. Finally, the domestic sewage exclusion in 40 CFR 261.4(a)(1), which excludes domestic sewage and any mixture of domestic sewage and other wastes that passes through a sewer system from being considered solid wastes (with some exceptions), applies to the POTW influent.</P>
                <P>Similarly, solid waste disposal facilities, such as municipal waste, or construction and demolition landfills would not be potentially affected by the RCRA corrective action requirements unless such facilities also operate as hazardous waste TSDFs.</P>
                <P>EPA solicits comment on the impacts of this rule on the RCRA Corrective Action Program and the interaction with other existing RCRA regulatory provisions including those non-corrective action provisions that reference hazardous constituents.</P>
                <HD SOURCE="HD2">E. What are the incremental costs and benefits of this action?</HD>
                <P>
                    EPA has evaluated the potential impacts and associated costs and benefits of this proposed rule. The draft Economic Assessment (EA) for this action, 
                    <E T="03">Economic Assessment of the Potential Costs, Benefits, and Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents</E>
                     (Ref. 41), is available in the docket for this action. If finalized, the quantifiable direct annual social cost of this proposed rule is estimated to be negligible, as EPA anticipates no significant direct impacts (see Sections II.A. and II.D. of this preamble).
                </P>
                <P>However, listing the specific PFAS as RCRA hazardous constituents may have indirect, indeterminate impacts associated with potential increases in the speed, extent, and total number of corrective action activities at certain TSDFs to address PFAS releases. Such potential increases are dependent upon subsequent actions and numerous factors, including decisions made and implemented by the permitting authority regarding associated corrective actions at certain TSDFs.</P>
                <P>RCRA Corrective Action Program implementers already have authority to require investigation and cleanup at RCRA TSDFs for substances not identified as hazardous constituents either through state cleanup regulations, or through the authority provided by section 270.32(b)(2), EPA's omnibus authority, and authorized state analogues. In addition, cleanup at TSDFs can also be required or conducted pursuant to CERCLA, such as ongoing DOD PFAS investigations and responses under CERCLA. EPA has also proposed to designate certain PFAS as CERCLA hazardous substances (see 87 FR 54415; September 6, 2022). It is uncertain how many investigative and response actions for releases of these nine PFAS, and their salts, and structural isomers, would occur under the authority of this rule that would not have occurred absent this rule under one of these other authorities.</P>
                <P>
                    While there are significant uncertainties about potential indirect impacts and the precise costs and benefits associated with corrective action are nonquantifiable due to these significant uncertainties, EPA provides hypothetical scenarios for how corrective action activity costs may increase for certain TSDFs as a result of 
                    <PRTPAGE P="8611"/>
                    addressing PFAS contamination. EPA also considers potential indirect benefits associated with corrective action, including avoided risk exposures, improved waste management practices, and improved quality of information about PFAS cleanup efforts. Other indirect effects may be experienced as a result of hastened investigative and cleanup activities that would otherwise be implemented pursuant to RCRA or other authorities which are not predicated upon a hazardous constituent determination. The full discussion of direct and indirect impacts is presented in the EA, which can be found in the public docket. EPA requests comment on specific aspects of the EA; see EA sections 4.3.3.1, 4.3.3.2, and 5.3.4.5. EPA also solicits comment on whether the potential impacts of this rulemaking may be affected by the availability of other authorities that program implementers might rely on to satisfy corrective action requirements to address PFAS at RCRA facilities including other RCRA authorities such as omnibus permitting authority and RCRA section 7003, and CERCLA.
                </P>
                <HD SOURCE="HD1">III. Legal Authority</HD>
                <HD SOURCE="HD2">A. What is the Agency's authority for taking this action?</HD>
                <P>EPA is proposing these regulations under the authority of sections 2002(a), 3001, and 3004 of the Solid Waste Disposal Act of 1965, as amended by the Resource Conservation and Recovery Act of 1976 (RCRA), as amended, by the Hazardous and Solid Waste Amendments of 1984 (HSWA), among other amendments, 42 U.S.C. 6912(a), 6921, and 6924. These public laws combined are commonly referred to as the “Resource Conservation and Recovery Act” (RCRA) and will be referred to as such for the remainder of this notice.</P>
                <P>
                    RCRA was enacted to effectively manage hazardous and solid wastes and thereby protect human health and the environment. RCRA 2002(a) provides EPA the general authority to prescribe regulations to carry out the functions of RCRA. RCRA section 3001 provides EPA with the authority to promulgate criteria for identifying and listing hazardous waste, and to identify and list hazardous wastes based on those criteria.
                    <SU>6</SU>
                    <FTREF/>
                     On May 19, 1980, EPA promulgated the initial list of hazardous constituents under this authority, which serve as part of the criteria for listing hazardous wastes,
                    <SU>7</SU>
                    <FTREF/>
                     40 CFR part 261, Appendix VIII. EPA has amended Appendix VIII several times to list or delete hazardous constituents. The criteria for listing substances as RCRA hazardous constituents on Appendix VIII are specified under 40 CFR 261.11(a)(3). The criteria state that substances will be listed on Appendix VIII “only if they have been shown in scientific studies to have toxic, carcinogenic, mutagenic or teratogenic effects on humans or other life forms.”
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         RCRA section 3001(a) and (b), 42 U.S.C. 6921(a), (b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Hazardous Waste Management System: Identification and Listing of Hazardous Waste, 45 FR 33084, May 19, 1980.
                    </P>
                </FTNT>
                <P>
                    The 1984 Hazardous and Solid Waste Amendments (HSWA) to RCRA expanded EPA's authority to address releases of hazardous waste and constituents at RCRA treatment, storage, and disposal facilities. This includes section 3004(u) and (v) of RCRA, which provides for corrective action requirements at permitted facilities. Section 3004(u) authorizes EPA to promulgate standards requiring corrective action for all releases of hazardous waste and hazardous constituents from solid waste management units at permitted hazardous waste treatment, storage, or disposal facilities regardless of the time at which waste was placed in the units.
                    <SU>8</SU>
                    <FTREF/>
                     Section 3004(u) further mandates that permits require financial assurance for completion of corrective action.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         Section 3004(u) provides that “standards promulgated under this section shall require, and a permit issued . . . by the Administrator or a State shall require, corrective action for all releases of hazardous waste or constituents from any solid waste management unit . . . regardless of the time at which waste was placed in such unit.”
                    </P>
                </FTNT>
                <P>Section 3004(v) directed EPA to require that corrective action be taken beyond facility boundaries where necessary to protect human health and the environment unless facility owners/operators demonstrate to the Agency's satisfaction that, despite their best efforts, they were unable to obtain the necessary permission to undertake off-site corrective action. 40 CFR 264.101 essentially codifies these RCRA section 3004(u) and (v) requirements. EPA has interpreted the hazardous constituents subject to corrective action as including those constituents identified in 40 CFR part 261 Appendix VIII and 40 CFR part 264 Appendix IX, 55 FR 30798, 30809 (July 27, 1990).</P>
                <P>A significant part of EPA's objective in proposing to add the new constituents to Appendix VIII is to ensure that releases of those substances can be effectively and efficiently considered and addressed through corrective action. In addition, the principal regulatory impact of this action would be to expand the scope of constituents subject to routine consideration in the corrective action process. Therefore, EPA is relying on its authority under RCRA section 3004(u) to propose listing these PFAS as hazardous constituents for the purposes of corrective action.</P>
                <HD SOURCE="HD2">B. RCRA Sections 3001 and 3004(u) Preclude Consideration of Cost in Identifying Hazardous Constituents</HD>
                <P>
                    In RCRA section 3001, Congress directed EPA to promulgate criteria for identifying the characteristics of hazardous waste and listing hazardous waste. Cost has no bearing on whether a material is hazardous, under the ordinary meaning of the word. Consistent with this ordinary meaning, Congress directed EPA to take into account “toxicity, persistence, and degradability in nature, potential for accumulation in tissue, and other related factors such as flammability, corrosiveness, and other hazardous characteristics.” RCRA section 3001(a); 
                    <E T="03">see also,</E>
                     RCRA section 3001(b) (“such as identified carcinogens, mutagens, or teratogens”). These statutory factors focus on various hazardous characteristics. Congress did not list cost as a required or permissible factor, and none of the Congressionally-listed statutory factors encompass a consideration of costs. This reflects the Agency's longstanding position. 
                    <E T="03">See,</E>
                     Hazardous Waste Management System: Identification and Listing of Hazardous Waste, 45 FR 33084, 33089, May 19, 1980. Additionally, determining whether something is “toxic” or has any of the other identified characteristics described in section 3001 does not naturally lend itself to considerations of cost—that is, whether a substance is or is not toxic is determined by examining the properties of the substance at issue.
                </P>
                <P>In carrying out this statutory obligation, EPA has promulgated regulatory criteria for adding constituents to Appendix VIII. Consistent with the health- and hazard- related factors identified in section 3001(a) and (b), these criteria (“toxic, carcinogenic, mutagenic or teratogenic effects on humans or other life forms.”), 40 CFR 261.11(a)(3), do not include cost nor does cost have any bearing or relevance on them.</P>
                <P>
                    EPA interprets the RCRA section 3004(u) corrective action standard-setting authority as authorizing the identification of hazardous constituents subject to corrective action. Moreover, Congress identified Appendix VIII as the source for the hazardous constituents referenced in 3004(u). 
                    <E T="03">See</E>
                      
                    <PRTPAGE P="8612"/>
                    H.R. REP. 98-198, 98th Cong., 1st Sess., pt. 1 at 60-61 (1983), reprinted in 1984 U.S.C.C.A.N. 5576, 5619-20. (“The term `hazardous constituent' as used in this provision is intended to mean those constituents listed in Appendix VIII of the RCRA regulations.”). As discussed above, cost is not a relevant consideration under the ordinary meaning of “hazardous.” Thus, as under section 3001, cost may not be considered in identifying hazardous constituents under section 3004(u).
                </P>
                <P>If finalized, this rule may have indirect, indeterminate costs and benefits associated with the speed, extent, and total number of corrective action activities at certain TSDFs to address these nine PFAS, their salts, and their structural isomers. EPA has presented cost and benefit information consistent with Executive Order 12866 in the EA for this rule, but these costs and benefits do not form any part of EPA's decision to designate these PFAS substances as hazardous constituents.</P>
                <HD SOURCE="HD1">IV. Background</HD>
                <HD SOURCE="HD2">A. What are PFAS?</HD>
                <P>Per- and polyfluoroalkyl substances, also known as PFAS, are a class of manufactured chemicals that have been widely used in many industrial and consumer products since the 1940s, and they are still being used today. PFAS have been or are currently being manufactured for a variety of different uses, ranging from adhesives, coatings for clothes and furniture, fire-fighting foam, and other uses. PFAS have been released into the environment during the manufacturing process and from various uses in industrial, commercial, and consumer settings.</P>
                <P>
                    PFAS have carbon chains with fluorine atoms attached to the carbons potentially linked to functional groups. Because the carbon-fluorine bond is the strongest known single carbon bond, these chemicals do not degrade readily in the environment (Ref. 7). However, some bigger molecules where a portion of the molecule has fluorinated carbons, known as precursors, can degrade or transform into other PFAS that are known to be toxic and are potentially mobile in the subsurface environment. For example, each of the nine PFAS that are the subject of this proposed rulemaking could be present as a result of degradation of a precursor. This proposed rulemaking applies to the PFAS identified in this action regardless of whether they exist as chemical substances on their own or result from degradation of precursors. There are thousands of different PFAS (
                    <E T="03">https://comptox.epa.gov/dashboard/chemical-lists/PFASMASTER</E>
                    ), some of which have been more widely used and studied than others. A growing body of scientific evidence shows that exposure to certain PFAS can adversely impact human health and other living things.
                </P>
                <HD SOURCE="HD2">B. What has been learned from PFAS toxicity studies?</HD>
                <P>
                    Certain PFAS, such as perfluorinated alkyl acids (
                    <E T="03">e.g.,</E>
                     PFOA, PFOS), are manufactured in both acid and salt forms. In aqueous environments, such as groundwater or the digestive system of humans and other animals, the acids and salts will dissociate into the ion form. Exposure to the salts or acid form of certain PFAS have been shown to lead to similar toxicity, as it has often been the salt form used in experimental animal toxicity studies.
                </P>
                <P>PFAS may also be present in products and in the environment as mixtures of linear and branched isomers, depending on the methods by which they are manufactured. Most studies do not clearly state what isomers were used, but of those that do, a mixture of linear and branched isomers was generally used. Studies generally only state the material purity, but purity does not refer to isomeric mixture. As a result, it's not currently practicable to differentiate the toxicity of the individual isomers, including the linear isomer. Therefore, any reference in this proposal to toxicity and health effects or listing of the nine PFAS as hazardous constituents on Appendix VIII includes the acids, salts, and structural isomers of the nine PFAS.</P>
                <HD SOURCE="HD1">V. Review of the Available Toxicity and Health Effects Information for PFAS</HD>
                <HD SOURCE="HD2">A. PFAS Identified To Have Sufficient Information To Be Evaluated for Appendix VIII Listing Criteria</HD>
                <P>EPA's evaluation of the available toxicity and health effects information for PFAS focused on PFAS that have final peer reviewed assessments and those with toxicity studies supporting ongoing assessments. The toxicity and health effects assessments that EPA is relying on for this proposal are those published by EPA and the Agency for Toxic Substances and Disease Registry (ATSDR).</P>
                <P>The EPA published a final peer reviewed toxicity and health effects assessment for PFOA and PFOS in 2016 (Ref. 9 and 14). Updated, draft toxicity and health effects assessments for PFOA and PFOS were published in 2023 as part of EPA's proposed National Primary Drinking Water Regulation for specific PFAS (Ref. 10 and 11). In 2021, EPA published a final peer reviewed toxicity and health effects assessment for PFBS (Ref. 15) and for HFPO-DA (Ref. 16). EPA published final peer reviewed toxicity and health effects assessments for PFBA in 2022 (Ref. 17) and PFHxA in 2023 (Ref. 32). EPA published a draft toxicity and health effects assessment for PFDA in 2023 and sought public comment and external peer review (Ref. 31), the final peer review report has been published (Ref. 45). EPA's ongoing toxicity and health effects assessment process for PFDA is expected to be finalized in the near future. EPA also released a draft toxicity and health effects assessment for PFHxS in 2023 and sought public comment and external peer review (Ref. 44). EPA's ongoing toxicity and health effects assessment for PFNA is in progress. ATSDR, in their 2021 Toxicological Profile for Perfluoroalkyls, reviewed toxicity information for twelve PFAS including PFOA, PFOS, PFBS, PFBA, PFHxA, PFNA, PFDA, and PFHxS (Ref. 18). In this Profile ATSDR derived toxicity values for PFOA, PFOS, PFNA, and PFHxS.</P>
                <P>Assessments conducted by EPA, ATSDR, and information published in scientific studies support the conclusion that PFOA, PFOS, PFBS, HFPO-DA, PFBA, PFNA, PFHxS, PFDA, and PFHxA warrant a hazardous constituent designation.</P>
                <P>
                    It should be noted that EPA's criteria for listing a substance as a hazardous constituent on Appendix VIII under 40 CFR 261.11(a)(3) do not require a finalized toxicity assessment, or exhaustive search and evaluation of all published scientific studies for the substance, or a final toxicity value. Rather, the criteria for listing substances on Appendix VIII only require that scientific studies have shown one or more of the criteria effects for the substances (
                    <E T="03">i.e.,</E>
                     toxic, carcinogenic, mutagenic or teratogenic effects).
                </P>
                <P>The Agency's evaluation has determined that more than the required scientific information showing toxic, carcinogenic, mutagenic or teratogenic effects already exists to list the selected PFAS as RCRA hazardous constituents.</P>
                <HD SOURCE="HD2">B. Summary of Toxicity and Health Effects Information for the Nine PFAS</HD>
                <P>
                    Below are brief summaries of the toxicity and adverse health effects information for the nine PFAS from the final peer reviewed assessments or toxicity studies supporting ongoing assessments. Please see the list of references and docket for this proposed rule to completely examine these assessments and studies which form the basis of EPA's proposed conclusions that these PFAS, their salts, and their 
                    <PRTPAGE P="8613"/>
                    structural isomers meet the criteria for listing as RCRA hazardous constituents.
                </P>
                <P>
                    Interpreting epidemiology data for PFAS and determining the individual toxicological responses of each PFAS individually (or their interaction effects) is an ongoing challenge because multiple PFAS have been shown to induce similar adverse health effects (
                    <E T="03">e.g.,</E>
                     immune, developmental, hepatic, cardiovascular effects, cancer). This is a subject where the science is rapidly evolving.
                </P>
                <HD SOURCE="HD3">1. PFOA</HD>
                <P>Human epidemiology data report associations between PFOA exposure and high cholesterol, increased liver enzymes and serum lipid levels, decreased vaccination response, thyroid disorders, pregnancy-induced hypertension and preeclampsia, cancer (testicular and kidney), and decreases in birth weight (Refs. 9 and 18).</P>
                <P>Oral animal studies of short-term subchronic and chronic duration are available in multiple species including monkeys, rats, and mice. These studies report developmental effects, liver toxicity including degenerative and necrotic effects, kidney toxicity, immune effects including impaired response to antigens, and cancer (liver, testicular, and pancreatic). Developmental effects observed in animals include decreased survival, delayed eye opening and reduced ossification, skeletal defects, altered puberty (delayed vaginal opening in females and accelerated puberty in males), and altered mammary gland development (Refs. 9 and 18).</P>
                <P>
                    There has been consistent evidence of associations between PFOA exposure and immunosuppression including reduced response to vaccines. Epidemiology studies have looked at the effects of exposure to several PFAS. In one study (Ref. 22), large datasets have been used to mutually adjust for concomitant PFAS exposures. Epidemiological studies have associated decreased vaccine response in children with elevated levels of PFOA in sera (Refs. 19, 20, 21, 22 and 40). Epidemiological studies have also indicated an increased risk of renal cell carcinoma with PFOA exposure (Refs. 42 and 43). An association with increased risk of ulcerative colitis has also been observed. The results of several mouse studies reported findings consistent with the epidemiological data suggesting that exposure to PFOA can result in immunosuppression (Ref. 18).
                    <SU>9</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         It is important to note that in March 2023, EPA proposed a National Primary Drinking Water Regulation for certain PFAS, including PFOA and PFOS (88 FR 18638; March 29, 2023). To support this rule, EPA developed and released updated draft toxicity assessments for PFOA and PFOS for public comment, to which EPA is currently responding (Refs. 10 and 11). The draft toxicity assessments underwent external peer review through EPA's Science Advisory Board PFAS Review Panel (Ref. 12), and EPA responded to the SAB's recommendations in the updated draft toxicity assessments (Ref. 13).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. PFOS</HD>
                <P>Epidemiology data report associations between PFOS exposure and high cholesterol, decreased vaccination response, and altered reproductive and developmental parameters including low birth weight. The strongest associations are related to serum lipids with increased total cholesterol and high-density lipoproteins (HDLs), and there are also associations with increases in serum enzymes and decreases in serum bilirubin (Refs. 14 and 18). There is suggestive epidemiological evidence for an association between serum PFOS and pregnancy-induced hypertension and/or pre-eclampsia (Ref. 18). Data also suggest a correlation between higher PFOS levels and decreases in female fecundity and fertility, in addition to decreased body weights in offspring, and other measures of postnatal growth (Ref. 14).</P>
                <P>There is consistent evidence of immunotoxicity after PFOS exposure. There is evidence of an association between serum PFOS levels and decreased antibody responses to vaccines in children (Ref. 18). Epidemiology studies have looked at the effects of exposure to several PFAS. In one study (Ref. 22), large datasets have been used to mutually adjust for concomitant PFAS exposures. Epidemiological studies have indicated decreased vaccine response in children associated with elevated levels of PFOS in sera (Refs. 19, 20, 21, 22 and 40). Rodent studies have also shown immunotoxicity after PFOS exposure (Ref. 18).</P>
                <P>Short-term and chronic exposure studies in animals consistently demonstrate increases in liver weight with co-occurring effects that include decreased cholesterol, hepatic steatosis, lower body weight, and liver histopathology (Ref. 14). Some degenerative and necrotic effects that are likely relevant to humans have been observed (Ref. 18). One and two generation toxicity studies also show decreased pup survival and body weights. Additionally, developmental neurotoxicity studies show increased motor activity and decreased habituation and increased escape latency in the water maze test following in utero and lactational exposure to PFOS. Gestational and lactational exposures were also associated with higher serum glucose levels and evidence of insulin resistance in adult offspring (Ref. 14).</P>
                <HD SOURCE="HD3">3. PFBS</HD>
                <P>Asthma and serum cholesterol levels in humans were found to exhibit a statistically significant positive association with PFBS exposure. No studies have been identified that evaluate the association between PFBS exposure and potential cancer outcomes (Ref. 15).</P>
                <P>
                    The limited number of human studies examining oral PFBS exposure does not inform the potential for effects in thyroid, developing offspring, or the renal system (Ref. 15). Animal studies of repeated-dose PFBS exposure have been exclusively via the oral route, used the potassium salt of PFBS as the source exposure material, and have examined noncancer effects only. The available rat and mouse studies support identification of thyroid, developmental, and kidney endpoints as potential health effects following repeated exposures in utero and/or during adulthood. Thyroid effects in exposed adult rats and mice and in developing mice were primarily expressed through significant decreases in circulating levels of hormones such as thyroxine and triiodothyronine. In early developmental life stages in mice (
                    <E T="03">e.g.,</E>
                     newborn), decreases in thyroid hormones were accompanied by other effects indicative of delayed maturation or reproductive development (
                    <E T="03">e.g.,</E>
                     vaginal patency and eyes opening). Kidney weight and/or histopathological alterations (
                    <E T="03">e.g.,</E>
                     renal tubular and ductal epithelial hyperplasia) were observed in rats following short-term and subchronic oral exposures. Many of the kidney effects, however, occurred at higher doses than did the thyroid and developmental effects.
                </P>
                <P>Animal studies have also evaluated other health outcomes, such as liver effects, reproductive parameters, lipid/lipoprotein homeostasis, and effects on the spleen and blood; however, the evidence currently available does not support a clear association with PFBS exposure and these outcomes (Ref. 15).</P>
                <HD SOURCE="HD3">4. HFPO-DA (GenX)</HD>
                <P>
                    Most of the available data for HFPO-DA and its ammonium salt (also known as GenX chemicals) were submitted to EPA by the manufacturer (DuPont/Chemours) under the Toxic Substances Control Act (TSCA), as required by TSCA reporting requirements (15 U.S.C. 
                    <PRTPAGE P="8614"/>
                    2607.8(e)) or pursuant to a consent order (Ref. 23).
                </P>
                <P>Oral toxicity studies for HFPO-DA and its ammonium salt were available for acute, short-term, subchronic, and chronic durations of exposure in rats and mice. These studies reported liver effects (increased relative liver weight, hepatocellular hypertrophy, single cell necrosis and apoptosis), kidney effects (increased relative kidney weight), immune effects (antibody suppression), developmental effects (increased early deliveries and delays in genital development), and tumorigenesis (liver and pancreatic tumors) (Ref. 16). Overall, the weight of the scientific evidence indicates the liver as a sensitive target for toxicity (meaning the liver is most susceptible to the toxic effects); however, the available data are inadequate to determine the mode of action for these effects.</P>
                <P>EPA's Office of Water followed current EPA risk assessment guidance and recommendations to select points of departure from the available animal studies for RfD derivation to support risk characterization. EPA also conducted literature searches to identify publicly available peer-reviewed hazard studies on HFPO-DA and its ammonium salt. All laboratory animal studies containing dose-response information were evaluated for study quality using an approach consistent with the Office of Research and Development's Handbook for developing IRIS assessments (Ref. 25).</P>
                <P>
                    EPA selected an oral reproductive/developmental toxicity study in mice (Ref. 26) showing hepatotoxicity (
                    <E T="03">i.e.,</E>
                     cytoplasmic alterations, apoptosis, single-cell necrosis, and focal necrosis) as the critical study and effect, respectively. Selection of this effect (liver toxicity) is supported by the National Toxicology Program Pathology Working Group's conclusion that the dose response for the constellation of liver lesions observed following oral exposure to HFPO-DA and its ammonium salt represents an adverse (rather than adaptive) response. The National Toxicology Program Pathology Working Group's Final Report on the Pathology Peer Review of Liver Findings is Appendix D of EPA's Human Health Toxicity Values for Hexafluoropropylene Oxide (HFPO) Dimer Acid and Its Ammonium Salt (CASRN 13252-13-6 and CASRN 62037-80-3, Ref. 16). Further support for the selection of liver toxicity as a critical effect was obtained from additional animal studies showing similar hazard outcomes (
                    <E T="03">i.e.,</E>
                     increased liver enzyme levels, histopathological lesions, and tumors) in both male and female mice and rats following various durations and levels of exposure (Ref. 16).
                </P>
                <HD SOURCE="HD3">5. PFNA</HD>
                <P>The available epidemiological studies suggest associations between PFNA and several health outcomes including increases in serum hepatic enzymes, particularly alanine aminotransferase (Ref. 18). Numerous studies have evaluated the hepatic toxicity of PFNA. The observed effects are consistent with effects observed for other perfluoroalkyl acids such as PFOA including alterations in serum lipid levels (Ref. 18). An epidemiological study has also indicated increased risk of renal cell carcinoma with exposure to PFNA, especially within African-Americans (Ref. 43).</P>
                <P>Some studies have found associations between serum PFNA and diphtheria and tetanus antibody levels. Grandjean and associates found a significant inverse association between diphtheria antibodies levels at age 5 and serum PFNA levels at age 5, but not for antibody levels at age 13 and PFNA levels at age 7 or 13. Some others also reported an inverse association between serum PFNA and diphtheria antibody levels in a small study of adults. An inverse association between maternal serum PFNA and rubella antibody levels was observed in children (Refs. 19, 20, 21, 22, and 24). Timmermann et al. found each 1 ng/mL increase in serum concentrations of PFNA was associated with decreases of 39% (95% CI: -4-64%) in diphtheria antibody concentrations (Ref. 40).</P>
                <P>Animal studies have also shown detrimental health effects. Two weeks after a single administration of PFNA in mice, Kielsen et al. also observed a number of immunological alterations (Ref. 24). Two acute-duration studies have evaluated the reproductive toxicity of PFNA in male rats. PFNA exposure resulted in decreases in serum testosterone and increases in serum estradiol levels and morphological changes. These changes as well as others were suggestive of damage to the secretory function of the Sertoli cells. In mice administered PFNA for 90 days, decreases in sperm motility, viability, and count and degenerative changes in the seminiferous tubules were observed. When the mice were mated with unexposed females, significant decreases in litter size were observed (Ref. 18).</P>
                <P>Three studies were identified that examined the developmental toxicity of PFNA in laboratory animals. Full litter resorptions were observed in mice administered PFNA, and maternal weight loss was also observed. Decreases in postnatal survival were observed. Decreases in birth weight were observed in female offspring of rats. Postnatal growth was decreased in the offspring of mice, and the decreases in body weight persisted in the pups. Reductions in nephron endowment (number of functioning nephrons at birth) were observed in male rat pups. Delays in eye opening and decrease in pup body weight gain were observed in offspring of mice administered PFNA (Ref. 18).</P>
                <HD SOURCE="HD3">6. PFHxS</HD>
                <P>The available epidemiological studies suggest associations between PFHxS and several health outcomes including decreased antibody response to vaccines in humans and increases in serum lipids, particularly total cholesterol and low-density lipoprotein (LDL) cholesterol, in animals (Ref. 18). EPA has released a draft assessment for PFHxS for public comment (Ref. 44).</P>
                <P>Epidemiology studies have looked at the effects of exposure to several PFAS. In one study (Ref. 22), large datasets have been used to mutually adjust for concomitant PFAS exposures. Epidemiological studies have indicated decreased vaccine response in children associated with elevated levels of PFHxS in sera (Refs. 19, 20, 21, 22, and 40). Inverse associations were observed between tetanus antibody levels in 5- and 7-year-old children and PFHxS levels in maternal serum and in children at age 5. A study in 3-year-old children found an inverse association between maternal PFHxS levels and rubella antibody levels, but no association with influenza type B or tetanus antibody levels. In adolescents, serum PFHxS levels were also inversely associated with rubella antibody titers in a seropositive subcohort (Ref. 18). Timmermann et al. found each 1 ng/mL increase in serum concentrations of PFHxS was associated with decreases of 78% (95% CI: 25-94%) in diphtheria antibody concentrations.</P>
                <P>Centrilobular hepatocellular hypertrophy was observed in rodents. Microvascular fatty changes were also observed. In male mice, dietary exposure to PFHxS in a western-type diet resulted in decreases in plasma triglyceride, total cholesterol, non-HDL cholesterol, and HDL cholesterol levels and decreases in the hepatic production of VLDL. Increases in liver weight and hepatic triglyceride levels were also observed (Ref. 18).</P>
                <HD SOURCE="HD3">7. PFDA</HD>
                <P>
                    PFDA has been associated with cardiovascular disease, immunological 
                    <PRTPAGE P="8615"/>
                    affects, and developmental affects. In this subsection, limited human and then animal evidence for potentially related health end points are discussed together for each end point. EPA has released a draft assessment for PFDA for public comment (Ref. 31).
                </P>
                <P>In a study of NHANES participants, Huang et al. (Ref. 27) found an increased risk of any type of cardiovascular disease among participants with the highest serum PFDA levels when the statistical analyses adjusted for serum total protein levels and estimated glomerular filtration rate; however, no associations were found for specific types of cardiovascular disease. Death in female mice following administration of a single lethal dose of PFDA by gavage was associated with mural thrombosis of the left ventricle of the heart. Non-lethal doses did not cause gross or microscopic alterations in the heart, assessed 30 days after dosing, but significantly decreased relative heart weight. Significant decrease in mean corpuscular hemoglobin and mean corpuscular hemoglobin concentration were observed in rats administered PFDA for 28 days (Ref. 18).</P>
                <P>Epidemiology studies have looked at the effects of exposure to several PFAS. In one study, large datasets have been used to mutually adjust for concomitant PFAS exposures. Epidemiological studies have indicated decreased vaccine response in children associated with elevated levels of PFDA in sera (Refs. 19, 20, 21, 22, and 40). Inverse associations were observed between serum PFDA levels at age 5 and tetanus antibody levels at ages 5 and 7 (Ref. 19) and serum PFDA levels at age 7 and antibody levels at age 13 (Ref. 20). Similarly, diphtheria antibody levels at age 13 were inversely associated with serum PFDA levels at age 7 years (Ref. 20). In adults, diphtheria antibody levels were inversely associated with serum PFDA levels, but there was no association for tetanus antibody levels.</P>
                <P>In case-control studies, associations between asthma diagnosis and asthma severity were observed in children; associations with serum immunoglobulin E levels, absolute eosinophil counts, and eosinophil cationic protein levels were also observed. A case-control study in adolescents found significantly higher serum PFDA levels among the asthmatic cases (Ref. 18).</P>
                <P>Lind et al. found an inverse association between maternal PFDA levels and anogenital distance in human girls, but not in boys (Ref. 28). An increase in fetal mortality was observed in mice exposed to PFDA, and PFDA was also associated with a marked decrease in fetal weight/litter, 100% incidence of variations in ossification of the braincase, decreases in maternal body weight, and maternal mortality (Ref. 18). Decreases in fetal body weight/litter in mice also were observed (Ref. 18).</P>
                <HD SOURCE="HD3">8. PFHxA</HD>
                <P>Although some human epidemiological studies have examined possible associations between PFHxA exposure and several adverse health outcomes, they are sparse and overall insufficient on their own to draw conclusions regarding adverse health effects. Based primarily on animal studies, certain PFHxA exposure levels have led to hepatic, developmental, hematopoietic, and endocrine effects (Refs. 18 and 32).</P>
                <P>In humans, an increased risk of cardiovascular disease (any type) was found in NHANES participants with higher serum PFHxA levels. A study of 70-year-old adults reported increases in the intima media thickness in the common carotid artery that was associated with serum PFHxA levels (Ref. 18). Several studies in rats have identified the hematological system as a target of PFHxA toxicity. Decreases in red blood cell counts, hemoglobin levels, and/or hematocrit levels and increases in reticulocyte levels have been observed in rats administered PFHxA (Refs. 18 and 32).</P>
                <P>Increases in liver weight, decreases in serum cholesterol levels, and centrilobular hepatocellular hypertrophy have been observed in rats administered PFHxA. In a chronic-duration study, gavage administration of PFHxA for 2 years resulted in increases in the incidence of hepatocellular necrosis in female rats. Decreases in triglyceride levels were observed in male rats (Ref. 18). Thus, the hepatic findings correlated with changes in clinical chemistry and necrosis (Ref. 32).</P>
                <P>Administration of PFHxA resulted in decreases in fetal weight in rats (Ref. 30). Similarly, decreases in pup body weight were observed in the offspring of rats administered PFHxA for 70 days prior to mating, during mating, and throughout gestation and lactation (Refs. 18 and 30).</P>
                <HD SOURCE="HD3">9. PFBA</HD>
                <P>Although several human epidemiological studies have examined possible associations between PFBA exposure and several adverse health outcomes, they are sparse and overall insufficient on their own to draw conclusions regarding toxic effects. Based primarily on animal studies, developmental, thyroid, and liver effects in humans are likely caused by PFBA exposure, given sufficient exposure conditions. In human studies, increases in the risk of hypertension in men and women, which was associated with serum PFBA levels, have been found. Systolic blood pressure levels were also associated with serum PFBA levels in men and women combined or in men only; no associations were found for diastolic blood pressure (Ref. 17).</P>
                <P>Oral doses of PFBA for 90 days resulted in significant reductions in red blood cell counts, hemoglobin, and hematocrit, and an increase in red blood cell distribution width in male rats. This dose level also caused a reduction in mean corpuscular hemoglobin and reduced mean corpuscular hemoglobin concentration in male rats. The lower hemoglobin and hematocrit observed in males were still detected at the end of a 3-week recovery period (Ref. 18).</P>
                <P>PFBA intermediate-duration studies have consistently found increases in liver weight and histological alterations. Dosing rats with PFBA resulted in significant increases in absolute and relative liver weight and decreases in serum cholesterol and hepatocellular hypertrophy (Ref. 17 and 18).</P>
                <P>Thyroid effects in adult exposed rats were expressed through decreases in free and total thyroxine (T4) and increased incidence of thyroid follicular hypertrophy and hyperplasia. Developmental effects in exposed animals were expressed as the loss of viable offspring (total litter resorption), and postnatal delays in postnatal developmental milestones: eye opening, vaginal opening, and preputial separation (Ref. 17).</P>
                <HD SOURCE="HD2">C. EPA's Proposed Conclusions on Whether the Nine PFAS, Their Salts, and Their Structural Isomers Meet the Criteria for Listing on Appendix VIII</HD>
                <P>The Agency's proposed conclusions are that the nine PFAS, their salts, and their structural isomers meet the criteria for listing as RCRA hazardous constituents on Appendix VIII because it has been shown through scientific studies referenced above that they have toxic effects on humans or other life forms.</P>
                <P>
                    The nine PFAS discussed in this proposed rule can occur in acid forms (
                    <E T="03">e.g.,</E>
                     perfluorooctanoic acid) and salt forms (
                    <E T="03">e.g.,</E>
                     ammonium perfluorooctanoate). Salts are deemed to have the same toxicity as the commonly referenced acid versions because, once put in water (and likewise when in human blood), the acid and salt forms will dissociate to the ionic form. Further, toxicity studies on PFAS were 
                    <PRTPAGE P="8616"/>
                    often performed using the salt form. Thus, EPA is proposing to list both acid and salt forms of the nine PFAS on Appendix VIII.
                </P>
                <P>Additionally, PFAS exist as linear and branched isomers, depending on the process used to manufacture them. For example, PFAS when manufactured through electrochemical fluorination consist of an isomeric mixture that is approximately 70% linear isomers and 30% branched isomers. The linear and branched isomers have been found in environmental media and in human sera. Most animal toxicity studies using isomeric mixtures do not state the ratio of linear and branched isomers in the test material, and, therefore, it is not feasible to distinguish the toxicity of the individual isomers. However, in a few studies, including Lieder et al. (2009) for PFBS, George and Andersen (1986) for PFDA, Bijland et al. (2011) for PFHxS, Butenhoff et al. (2004), Lau et al. (2006), and Lou et al. (2009) for PFOA, and Ankley et al. (2004) for PFOS (Refs. 33-39), the authors stated that the PFAS test substance was not 100% linear, and thus any effects indicated in these studies can only be associated with the isomeric mixture of linear and branched and not specifically with linear isomers or branched isomers. Further, Loveless et al. (2006) compared the toxicity of linear ammonium PFOA, branched ammonium PFOA, and a mixture of linear and branched ammonium PFOA in rodents, and demonstrated that both linear and branched isomers exhibit similar types of toxicity (Ref. 29). While toxicity studies such as these are not available for all PFAS included in this proposal, EPA believes it is both reasonable and public health protective, based on the available toxicity data for isomeric mixtures, to list the structural isomers. Thus, EPA is proposing to also list the structural isomers for the nine PFAS on Appendix VIII.</P>
                <HD SOURCE="HD1">VI. State Authorization</HD>
                <HD SOURCE="HD2">A. Applicability of the Rule in Authorized States</HD>
                <P>Under section 3006 of RCRA, 42 U.S.C. 6926, EPA may authorize a qualified State to administer and enforce a hazardous waste program within the State in lieu of the Federal program, and to issue and enforce permits in the State. Following authorization, EPA retains enforcement authority under sections 3008, 3013, and 7003 of RCRA, although authorized States have primary enforcement responsibility. The standards and requirements for State authorization are found at 40 CFR part 271.</P>
                <P>Prior to enactment of the Hazardous and Solid Waste Amendments of 1984 (HSWA), a State with final RCRA authorization administered its hazardous waste program entirely in lieu of EPA administering the Federal program in that State. The Federal requirements no longer applied in the authorized State, and EPA could not issue permits for any facilities in that State, since only the State was authorized to issue RCRA permits. When new, more stringent Federal requirements were promulgated, the State was obligated to enact equivalent authorities within specified timeframes. However, the new Federal requirements did not take effect in an authorized State until the State adopted the Federal requirements.</P>
                <P>In contrast, under RCRA section 3006(g), (42 U.S.C. 6926(g)) (which was added by HSWA), new Federal requirements and prohibitions imposed, pursuant to HSWA authority, take effect in authorized States at the same time that they take effect in unauthorized States. Although authorized States are still required to update their hazardous waste programs to remain equivalent to the Federal program, EPA is directed by the statute to implement the requirements and prohibitions in authorized States, including the issuance of new permits implementing those new requirements, until EPA authorizes the State to do so.</P>
                <P>
                    Authorized States are required to modify their programs only when EPA promulgates Federal requirements that are more stringent or broader in scope than existing Federal requirements. RCRA section 3009 allows the States to impose standards more stringent than those in the Federal program. 
                    <E T="03">See also</E>
                     40 CFR 271.1(i). If EPA promulgates a Federal requirement that is less stringent than an existing requirement, authorized States may, but are not required to, adopt the requirement regardless of whether it is a HSWA or non-HSWA requirement.
                </P>
                <HD SOURCE="HD2">B. Effect on State Authorization</HD>
                <P>This rule is promulgated pursuant to both non-HSWA authority (RCRA section 3001) and HSWA authority (RCRA section 3004(u)). The changes to Appendix VIII proposed in this rule are more stringent than the current Federal requirements because adding new substances to Appendix VIII expands the list of hazardous constituents that are subject to RCRA regulatory requirements. Therefore, States will be required to adopt and seek authorization for these changes. The Appendix VIII list of hazardous constituents does not by itself impose regulatory requirements. Rather, requirements to address hazardous constituents are found in various sections throughout the Federal hazardous waste regulations.</P>
                <P>Today's proposal, if finalized, would add nine PFAS, their salts, and their structural isomers to Appendix VIII for all purposes except corrective action, pursuant to RCRA section 3001. Today's action would also add these substances to Appendix VIII for corrective action purposes and add this listing action, as it would apply to corrective action purposes, to Table 1 in 40 CFR 271.1, pursuant to RCRA section 3004(u). Given the dual nature of today's proposal, EPA would consider the final rule to be a non-HSWA rule promulgated under RCRA 3001 for all purposes except corrective action under RCRA 3004(u) and (v), and would consider the final rule to be a HSWA rule as applied to such corrective action (for example, as applied to the scope of hazardous constituents subject to corrective action under 40 CFR 264.101, the principal regulation implementing these provisions). Thus, the addition of the nine PFAS, their salts, and their structural isomers, as applied to RCRA section 3004(u) and (v) corrective action would become immediately effective in all States on the effective date (which would be provided in any final notice for the action); and EPA would implement the new rule as applied to corrective action in all States until those States become authorized for the new rule.</P>
                <P>
                    States with authorized RCRA programs may already include one or more of these PFAS on their lists of hazardous constituents, since RCRA contemplates that States may promulgate regulations which are more stringent than the Federal RCRA requirements. These State regulations have not been assessed against the Federal regulations proposed today to determine whether they meet the authorization requirements. Thus, such a State would not be authorized to implement these regulations as RCRA requirements until the State program provisions are submitted to EPA and approved, pursuant to 40 CFR 271.21. Of course, States with existing regulations that are more stringent than or broader in scope than current Federal regulations may continue to administer and enforce their regulations as a matter of State law. In implementing the HSWA corrective action requirements, EPA will work with the States under agreements to avoid duplication of effort.
                    <PRTPAGE P="8617"/>
                </P>
                <HD SOURCE="HD1">VII. Statutory and Executive Order Reviews</HD>
                <P>
                    Additional information about these statutes and Executive Orders can be found at 
                    <E T="03">https://www.epa.gov/laws-regulations/laws-and-executive-orders</E>
                    .
                </P>
                <HD SOURCE="HD2">A. Executive Order 12866: Regulatory Planning and Review and Executive Order 14094: Modernizing Regulatory Review</HD>
                <P>
                    This action is a “significant regulatory action” as defined in Executive Order 12866, as amended by Executive Order 14094. Accordingly, EPA submitted this action to the Office of Management and Budget (OMB) for Executive Order 12866 review. Documentation of any changes made in response to Executive Order 12866 review is available in the docket. The EPA prepared an analysis of the potential impacts associated with this action. This analysis, the draft 
                    <E T="03">Economic Assessment of the Potential Costs, Benefits, and Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents</E>
                     (Ref. 41), is available in the docket for this action.
                </P>
                <HD SOURCE="HD2">B. Paperwork Reduction Act (PRA)</HD>
                <P>
                    This action does not impose an information collection burden under the provisions of the Paperwork Reduction Act, 44 U.S.C. 3501 
                    <E T="03">et seq.,</E>
                     because it does not contain any information collection activities. Burden is defined at 5 CFR 1320.3(b).
                </P>
                <HD SOURCE="HD2">C. Regulatory Flexibility Act (RFA)</HD>
                <P>
                    I certify that this action will not have a significant economic impact on a substantial number of small entities under the RFA, 5 U.S.C. 601, 
                    <E T="03">et seq.</E>
                     EPA projects negligible direct impacts to regulated entities associated with the proposed rule (see Sections II.A. and II.D.). To the extent the proposed rule may result in indirect costs associated with corrective action, the small entity analysis in the draft Economic Assessment identifies 75 small entities that could be impacted.
                </P>
                <P>
                    Because the proposed rule estimates negligible costs associated with direct impacts, EPA concludes the proposed rule will not result in a significant economic impact for a substantial number of small entities. Additional details of the small entity analysis, including information about the broader universe of TSDFs, are presented in the draft 
                    <E T="03">Economic Assessment of the Potential Costs, Benefits, And Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents (</E>
                    Ref. 41), available in the public docket for this action.
                </P>
                <HD SOURCE="HD2">D. Unfunded Mandates Reform Act (UMRA)</HD>
                <P>This action does not contain an unfunded mandate of $100 million or more as described in UMRA, 2 U.S.C. 1531-1538, and does not significantly or uniquely affect small governments because direct costs are projected to be negligible.</P>
                <HD SOURCE="HD2">E. Executive Order 13132: Federalism</HD>
                <P>This action does not have federalism implications based on EPA's policy for implementing E.O. 13132, entitled “Federalism.” It will not have substantial direct effects on the States or localities based on EPA's intergovernmental cost threshold for the E.O. 13132 analysis; it will not preempt State or local law or substantially affect the distribution of power and responsibilities among the various levels of government.</P>
                <HD SOURCE="HD2">F. Executive Order 13175: Consultation and Coordination With Indian Tribal Governments</HD>
                <P>
                    This action does not have tribal implications as specified in Executive Order 13175 because it does not have substantial direct effects on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes. There is only one facility on Tribal lands that EPA has identified that could be potentially affected by this rulemaking, and because the rule is not expected to result in substantial direct impacts (
                    <E T="03">i.e.,</E>
                     EPA anticipates negligible direct impacts) it is also not expected to result in adverse impacts on this tribal entity. Thus, Executive Order 13175 does not apply to this action.
                </P>
                <P>However, consistent with the EPA Policy on Consultation and Coordination with Indian Tribes, the EPA intends to consult with and request comments from the affected tribe and other tribal officials that wish to consult with the Agency on this rulemaking.</P>
                <HD SOURCE="HD2">G. Executive Order 13045: Protection of Children From Environmental Health Risks and Safety Risks</HD>
                <P>Executive Order 13045 (62 FR 19885, April 23, 1997) directs Federal agencies to include an evaluation of the health and safety effects of the planned regulation on children in Federal health and safety standards and explain why the regulation is preferable to potentially effective and reasonably feasible alternatives. This action is not subject to Executive Order 13045 because it is not “economically significant” as defined in Executive Order 12866, and because it does not concern an environmental health risk or safety risk. This action, which proposes to add nine PFAS, their salts, and their structural isomers as RCRA hazardous constituents, does not itself address environmental health or safety risks. Therefore, EPA does not believe there are disproportionate risks to children.</P>
                <P>
                    However, EPA's 2021 Policy on Children's Health applies to this action, which requires EPA to consider early life exposures and lifelong health consistently and explicitly in all human health decisions.
                    <SU>10</SU>
                    <FTREF/>
                     To the extent that the proposed rulemaking leads to the remediation of select PFAS, potential exposure to these PFAS is expected to be reduced for the population living in close proximity to these sites, including susceptible subpopulations such as workers and children. Additionally, to the extent that the proposed rule reduces exposure, a reduction in the risks of adverse health effects in children might be expected, as well as associated health care cost savings. The information that EPA used to evaluate the toxicity and health effects of these PFAS, which includes many studies that looked at effects during development and on children, is described above in the Section Summary of toxicity and health effects information for the nine PFAS and the supporting documents in the public docket for this action.
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/2021-policy-on-childrens-health.pdf</E>
                        .
                    </P>
                </FTNT>
                <HD SOURCE="HD2">H. Executive Order 13211: Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution or Use</HD>
                <P>This action is not a “significant energy action” because it is not related to, or likely to have a significant adverse effect on, the supply, distribution, or use of energy. This action proposes to add nine PFAS, their salts, and structural isomers as RCRA hazardous constituents, and thus, does not involve the supply, distribution, or use of energy.</P>
                <HD SOURCE="HD2">I. National Technology Transfer and Advancement Act (NTTAA)</HD>
                <P>
                    This rulemaking does not involve technical standards.
                    <PRTPAGE P="8618"/>
                </P>
                <HD SOURCE="HD2">J. Executive Order 12898: Federal Actions To Address Environmental Justice in Minority Populations and Low-Income Populations; Executive Order 14096: Revitalizing Our Nation's Commitment to Environmental Justice for All</HD>
                <P>Executive Order 14096 (88 FR 25251, Apr. 26, 2023) directs Federal agencies to advance the goal of environmental justice for all. This action builds upon and supplements the efforts of Executive Order 12898 (59 FR 7629, February 16, 1994) to address environmental justice.</P>
                <P>The EPA believes that the human health or environmental conditions that exist prior to this action may result in or have the potential to result in disproportionate and adverse human health or environmental effects on communities with environmental justice concerns.</P>
                <P>Several key demographic categories were analyzed relative to the universe of facilities potentially affected by the proposed rule. This proposed regulation identifies groundwater and surface water as potential sources of exposure for the identified PFAS. Due to uncertainty surrounding the location of PFAS releases, this analysis additionally considers a subset of the total universe of facilities which are associated with a potentially higher likelihood of handling PFAS, and where corrective action for PFAS may occur. These facilities are identified based on:</P>
                <EXTRACT>
                    <P>
                        • A list of NAICS codes (at the 6-digit level) used by Salvatore et al. (2022) for identifying presumptive PFAS contamination across the U.S.
                        <SU>11</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             See Salvatore et al., “Presumptive Contamination: A New Approach to PFAS Contamination Based on Likely Sources”, Environ Sci Technol Lett. Vol. 9, Issue 11. November 8, 2022. Accessed at: 
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9648201/</E>
                            .
                        </P>
                    </FTNT>
                    <P>• EPA's proposed rule, `Designation of Perfluorooctanoic Acid (PFOA) and Perfluorooctanesulfonic Acid (PFOS) as CERCLA Hazardous Substances', identified industries (at the 6-digit NAICS level) historically associated with PFAS; therefore, TSDFs in these industries are also assumed to have higher likelihood of handling PFAS.</P>
                    <P>
                        • The PFAS Analytical Tools page in EPA's Enforcement and Compliance History Online (ECHO) includes a list of industry sectors potentially associated with PFAS, defined by 6-digit NAICS.
                        <SU>12</SU>
                        <FTREF/>
                         Any permitted TSDFs within these industries are also assumed to have a higher likelihood of handling PFAS.
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             See United States Environmental Protection Agency, PFAS Analytical Tools, available at 
                            <E T="03">https://echo.epa.gov/trends/pfas-tools</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        • If a TSDF in the regulatory universe reported any of the specific PFAS proposed for addition to 40 CFR part 261, Appendix VIII in the EPA's Toxic Release Inventory (TRI),
                        <SU>13</SU>
                        <FTREF/>
                         that facility is also assumed to have a higher likelihood of handling PFAS.
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             PFAS chemicals included in search: PFOS, PFOA, PFBS, HFPO-DA (GenX), PFNA, PFHxS, PFDA, PFHxA, and PFBA. Environmental Protection Agency, “Envirofacts: TRI Search”, December 2022. Accessed at: 
                            <E T="03">https://www.epa.gov/enviro/tri-search</E>
                            .
                        </P>
                    </FTNT>
                </EXTRACT>
                <P>The sites identified as having potential association with PFAS make them a reasonable proxy for identifying where corrective action for these substances may be required and offer an associated surrounding demographic context. However, the spatial distribution and predicted risk factor of a PFAS release cannot be certain without further site-specific investigation into a facility's waste handling capacity, proximity to population centers, and interconnectivity of local environmental resources.</P>
                <P>The EPA believes that this action may indirectly reduce existing disproportionate and adverse effects on communities with environmental justice concerns. To the extent that the proposed rule leads to the remediation of releases for any of the nine PFAS, their salts, and their structural isomers that EPA proposes to list as RCRA hazardous constituents, health risks for populations living in close proximity to these sites (particularly populations that rely on private well water near these sites) may decline. As groundwater and surface water have been identified as potential exposure pathways of PFAS, the inclusion of private well usage rates in areas surrounding facilities known to use, produce, or release PFAS provides additional information about populations that may have a potentially higher likelihood of negative health outcomes from a PFAS release. In some cases, focusing the analysis solely on those potentially more vulnerable populations served by private wells reveals further demographic disparities compared to the total U.S. population served by private wells.</P>
                <P>
                    Details of the full analysis and findings are presented in the draft 
                    <E T="03">Economic Assessment of the Potential Costs, Benefits, and Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents</E>
                     (Ref. 41), which can be found in the public docket for this action.
                </P>
                <P>Better understanding the impacts of a PFAS release and the factors that determine the magnitude of effects on the surrounding human and natural environment will potentially become more apparent over time, allowing for improved information and a more robust analysis on any disproportionate and adverse outcomes experienced by populations with EJ concerns. This improved information would not increase risk for communities with EJ concerns and may improve the speed and design of remediation. The EPA is committed to minimizing and/or eliminating existing barriers and burdens that communities with EJ concerns may encounter related to accessing data and information associated with this rulemaking, if finalized. EPA seeks comment on strategies to improve access to associated data, which may become available in RCRA Info, for communities with environmental justice concerns.</P>
                <HD SOURCE="HD1">VIII. References</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        1. U.S. EPA. (2023). PFOA, PFOS and other PFAS: Basic information on PFAS. U.S. Environmental Protection Agency. 
                        <E T="03">https://www.epa.gov/pfas/basic-information-pfas.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        2. ATSDR. (2023). PFAS and Your Health. 
                        <E T="03">https://www.atsdr.cdc.gov/pfas/index.html.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        3. Public Employees for Environmental Responsibility (PEER) to the Administrator of EPA concerning RCRA Regulation of a Class of Wastes Containing PFAS. September 19, 2019. 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-09/peer_pfas_rulemaking_petition_metadata_added.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        4. Petition for Rulemaking from Environmental Law Clinic of University of California, Berkeley to the Administrator of EPA concerning RCRA Regulation of Wastes Containing Long-Chain PFASs and GenX Chemicals. January 15, 2020. 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-09/pfas_petition_for_haz_waste_jan_2020_metadata_added.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        5. Petition from the Governor of New Mexico to the Administrator of EPA concerning action on PFAS under RCRA. June 23, 2021. 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/508compliant_ezd5442262_2021-06-23-governor-letter-to-epa-for-pfas-petition.pdf-incoming-document.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        6. EPA Administrator's letter to the Governor of New Mexico in response to the petition on PFAS. October 26, 2021. 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/oct_2021_response_to_nm_governor_pfas_petition_corrected.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        7. NIEHS. (2023). Perfluoroalkyl and Polyfluoroalkyl Substances (PFAS). 
                        <E T="03">https://www.niehs.nih.gov/health/topics/agents/pfc/index.cfm.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        8. Press release on EPA's response to New Mexico Governor's petition on PFAS. October 26, 2021. 
                        <E T="03">https://www.epa.gov/newsreleases/epa-responds-new-mexico-governor-and-acts-address-pfas-under-hazardous-waste-law.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        9. U.S. EPA. (2016). Health effects support document for perfluorooctanoic acid (PFOA). U.S. Environmental Protection 
                        <PRTPAGE P="8619"/>
                        Agency Office of Water. EPA-822-R-16-003. 
                        <E T="03">https://www.epa.gov/sites/default/files/2016-05/documents/pfoa_hesd_final-plain.pd.f</E>
                    </FP>
                    <FP SOURCE="FP-2">10. U.S. EPA. (2023). Public Comment Draft—Toxicity Assessment and Proposed Maximum Contaminant Level Goal (MCLG) for Perfluorooctanoic Acid (PFOA) (CASRN 335-67-1) in Drinking Water. EPA-822-P-23-005.</FP>
                    <FP SOURCE="FP-2">11. U.S. EPA. (2023). Public Comment Draft—Toxicity Assessment and Proposed Maximum Contaminant Level Goal (MCLG) for Perfluorooctane Sulfonic Acid (PFOS) (CASRN 1763-23-1) in Drinking Water. EPA-822-P-23-007.</FP>
                    <FP SOURCE="FP-2">
                        12. U.S. EPA. (2022). Transmittal of the Science Advisory Board Report titled, “Review of EPA's Analyses to Support EPA's National Primary Drinking Water Rulemaking for PFAS.” EPA-22-008. 
                        <E T="03">https://sab.epa.gov/ords/sab/f?p=114:12:15255596377846</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">13. U.S. EPA. (2023). EPA Response to Final Science Advisory Board Recommendations (August 2022) on Four Draft Support Documents for the EPA's Proposed PFAS National Primary Drinking Water Regulation. EPA-822-D-23-001.</FP>
                    <FP SOURCE="FP-2">
                        14. U.S. EPA. (2016). Health effects support document for perfluorooctane sulfonate (PFOS). U.S. Environmental Protection Agency Office of Water. 
                        <E T="03">https://www.epa.gov/sites/default/files/2016-05/documents/pfos_hesd_final_508.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        15. U.S. EPA. (2021). Human Health Toxicity Values for Perfluorobutane Sulfonic Acid (CASRN 375-73-5) and Related Compound Potassium Perfluorobutane Sulfonate (CASRN 29420-49-3). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://www.epa.gov/chemical-research/learn-about-human-health-toxicity-assessment-pfbs.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        16. U.S. EPA. (2021). Human Health Toxicity Values for Hexafluoropropylene Oxide (HFPO) Dimer Acid and Its Ammonium Salt (CASRN 13252-13-6 and CASRN 62037- 80-3) Also Known as “GenX Chemicals.” U.S. Environmental Protection Agency Office of Water. 
                        <E T="03">https://www.epa.gov/system/files/documents/2021-10/genx-chemicals-toxicity-assessment_tech-edited_oct-21-508.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        17. U.S. EPA. (2022). IRIS Toxicological Review of Perfluorobutanoic Acid (PFBA) and Related Salts (Final Report). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://iris.epa.gov/static/pdfs/0701tr.pdf.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        18. ATSDR. (2021). Toxicological profile for perfluoroalkyls: final. Atlanta, GA: U.S. Department of Health and Human Services, Centers for Disease Control and Prevention, Agency for Toxic Substances and Disease Registry. 
                        <E T="03">https://stacks.cdc.gov/view/cdc/59198.</E>
                    </FP>
                    <FP SOURCE="FP-2">19. Grandjean et al. (2012). “Serum Vaccine Antibody Concentrations in Children Exposed to Perfluorinated Compounds” JAMA 307 (4): 391-397. DOI:10.1001/jama.2011.2034.</FP>
                    <FP SOURCE="FP-2">20. Grandjean et al. (2017). “Serum Vaccine Antibody Concentrations in Adolescents Exposed to Perfluorinated Compounds” Environ Health Perspect 125 (7): 077018 DOI: 10.1289/EHP275.</FP>
                    <FP SOURCE="FP-2">21. Grandjean et al. (2017). “Estimated exposures to perfluorinated compounds in infancy predict attenuated vaccine antibody concentrations at age 5-years” J Immunotoxicol 14 (1): 188-195. DOI: 10.1080/1547691X.2017.1360968.</FP>
                    <FP SOURCE="FP-2">22. Budtz-Jorgensen and Grandjean. (2018). “Application of benchmark analysis for mixed contaminant exposures: Mutual adjustment of perfluoroalkylate substances associated with immunotoxicity” PLoS One 13 (10): e0205388. DOI: 10.1371/journal.pone.0205388.</FP>
                    <FP SOURCE="FP-2">
                        23. U.S. EPA. (2009). Consent Order and Determinations Supporting Consent Order for Premanufacture Notice Numbers: P-08-508 and P-08-509. EPA, Office of Pollution Prevention and Toxics, Washington, DC. 
                        <E T="03">https://chemview.epa.gov/chemview/proxy?filename=sanitized_consent_order_p_08_0508c.pdf</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">24. Kielsen et al. (2016). Antibody response to booster vaccination with tetanus and diphtheria in adults exposed to perfluorinated alkylates. J Immunotoxicol 13(2):270-273.</FP>
                    <FP SOURCE="FP-2">25. U.S. EPA. (2020). ORD Staff Handbook for Developing IRIS Assessments (Public Comment Draft, Nov 2020). EPA/600/R-20/137. EPA, Office of Research and Development, Washington, DC.</FP>
                    <FP SOURCE="FP-2">26. DuPont-18405-1037: E.I. du Pont de Nemours and Company. 2010. An Oral (Gavage) Reproduction/Developmental Toxicity Screening Study of H-28548 in Mice. U.S. EPA OPPTS 870.3550; OECD Test Guideline 421. Study conducted by WIL Research Laboratories, LLC (Study Completion Date: December 29, 2010), Ashland, OH.</FP>
                    <FP SOURCE="FP-2">
                        27. Huang et al. (2018). Serum polyfluoroalkyl chemicals are associated with risk of cardiovascular diseases in national US population. Environ Int 119:37-46. 
                        <E T="03">http://doi.org/10.1016/j.envint.2018.05.051</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">
                        28. Lind et al. (2017). Prenatal exposure to perfluoroalkyl substances and anogenital distance at 3 months of age in a Danish mother-child cohort. Reprod Toxicol 68:200-206. 
                        <E T="03">http://doi.org/10.1016/j.reprotox.2016.08.019</E>
                        .
                    </FP>
                    <FP SOURCE="FP-2">29. Loveless et al. (2006). “Comparative responses of rats and mice exposed to linear/branched, linear, or branched ammonium perfluorooctanoate (APFO)” Toxicology 220(2-3): 203-17. DOI: 10.1016/j.tox.2006.01.003.</FP>
                    <FP SOURCE="FP-2">30. Loveless et al. (2009). “Toxicological evaluation of sodium perfluorohexanoate” Toxicology 264 (1-2): 32-44. DOI: 10.1016/j.tox.2009.07.011.</FP>
                    <FP SOURCE="FP-2">
                        31. U.S. EPA. (2023). IRIS Toxicological Review of Perfluorodecanoic Acid (PFDA) and Related Salts (Draft Report). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://cfpub.epa.gov/ncea/iris_drafts/recordisplay.cfm?deid=354408.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        32. U.S. EPA. (2023). IRIS Toxicological Review of Perfluorohexanoic Acid (PFHxA) and Related Salts (Final Report). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://cfpub.epa.gov/ncea/iris_drafts/recordisplay.cfm?deid=357314.</E>
                    </FP>
                    <FP SOURCE="FP-2">33. Lieder et al. (2009). “A two-generation oral gavage reproduction study with potassium perfluorobutanesulfonate (K+PFBS) in Sprague Dawley rats.” Toxicology 259 (1-2): 33-45. DOI: 10.1016/j.tox.2009.01.027.</FP>
                    <FP SOURCE="FP-2">34. George and Andersen (1986). “Toxic effects of nonadecafluoro-n-decanoic acid in rats.” Toxicology and Applied Pharmacology 85(2): 169-180. DOI: 10.1016/0041-008X(86)90110-9.</FP>
                    <FP SOURCE="FP-2">35. Bijland et al. (2011). “Perfluoroalkyl sulfonates cause alkyl chain length-dependent hepatic steatosis and hypolipidemia mainly by impairing lipoprotein production in APOE*3-Leiden CETP mice.” Toxicol Sci 123(1): 290-303. DOI: 10.1093/toxsci/kfr142.</FP>
                    <FP SOURCE="FP-2">36. Butenhoff et al. (2004). “The reproductive toxicology of ammonium perfluorooctanoate (APFO) in the rat.” Toxicology 196 (1-2): 95-116. DOI: 10.1016/j.tox.2003.11.005.</FP>
                    <FP SOURCE="FP-2">37. Lau et al. (2006). “Effects of perfluorooctanoic acid exposure during pregnancy in the mouse.” Toxicol Sci 90(2): 510-518. DOI: 10.1093/toxsci/kfj105.</FP>
                    <FP SOURCE="FP-2">38. Lou et al. (2009). “Modeling single and repeated dose pharmacokinetics of PFOA in mice.” Toxicol Sci 107(2): 331-41. DOI: 10.1093/toxsci/kfn234.</FP>
                    <FP SOURCE="FP-2">39. Ankley et al. (2004). “Partial life-cycle toxicity and bioconcentration modeling of perfluorooctanesulfonate in the northern leopard frog (Rana pipiens).” Environmental Toxicology and Chemistry 23(11): 2745-2755. DOI: 10.1897/03-667.</FP>
                    <FP SOURCE="FP-2">40. Timmermann et al. (2022). “Concentrations of tetanus and diphtheria antibodies in vaccinated Greenlandic children aged 7-12 years exposed to marine pollutants, a cross sectional study.” Environmental Research 203. DOI: 10.1016/j.envres.2021.111712.</FP>
                    <FP SOURCE="FP-2">41. U.S. EPA. (2023). Draft Economic Assessment of the Potential Costs, Benefits, and Other Impacts of the Proposed Rulemaking to List Specific PFAS as RCRA Hazardous Constituents. U.S. Environmental Protection Agency Office of Land and Emergency Management.</FP>
                    <FP SOURCE="FP-2">42. Shearer et al. (2021). “Serum Concentrations of Per- and Polyfluoroalkyl Substances and Risk of Renal Cell Carcinoma.” J Natl Cancer Inst. 113(5): 580-587. DOI: 10.1093/jnci/djaa143.</FP>
                    <FP SOURCE="FP-2">
                        43. Rhee et al. (2023). “Serum Concentrations of Per- and Polyfluoroalkyl Substances and Risk of Renal Cell Carcinoma in the Multiethnic Cohort Study.” Environmental International Volume 180, 108197. 
                        <E T="03">https://doi.org/10.1016/J.envint.2023.108197.</E>
                        <PRTPAGE P="8620"/>
                    </FP>
                    <FP SOURCE="FP-2">
                        44. U.S. EPA. (2023). IRIS Toxicological Review of Perfluorohexanesulfonic Acid (PFHxS) and Related Salts (Draft Report). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://cfpub.epa.gov/ncea/iris_drafts/recordisplay.cfm?deid=355410.</E>
                    </FP>
                    <FP SOURCE="FP-2">
                        45. U. S. EPA (2023). External Panel Peer Review of EPA's Draft “IRIS Toxicological Review of Perfluorodecanoic Acid (PFDA) and Related Salts” (Final Peer Review Report). U.S. Environmental Protection Agency Office of Research and Development. 
                        <E T="03">https://cfpub.epa.gov/ncea/iris_drafts/recordisplay.cfm?deid=354408.</E>
                    </FP>
                </EXTRACT>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects</HD>
                    <CFR>40 CFR Part 261</CFR>
                    <P>Environmental protection, Hazardous waste, Recycling, Reporting and recordkeeping requirements.</P>
                    <CFR>40 CFR Part 271</CFR>
                    <P>Administrative practice and procedure, Confidential business information, Environmental protection, Hazardous materials transportation, Hazardous waste, Indians—lands, Intergovernmental relations, penalties, and Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <SIG>
                    <NAME>Michael S. Regan,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
                <P>For the reasons set out in the preamble, EPA proposes to amend title 40, chapter I of the Code of Federal Regulations as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 261—IDENTIFICATION AND LISTING OF HAZARDOUS WASTE</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 261 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>42 U.S.C. 6905, 6912(a), 6921, 6922, 6924(y) and 6938.</P>
                </AUTH>
                <AMDPAR>2. Appendix VIII to Part 261 is amended by adding in alphabetical order the following entries:</AMDPAR>
                <HD SOURCE="HD1">Appendix VIII to Part 261—Hazardous Constituents</HD>
                <STARS/>
                <GPOTABLE COLS="4" OPTS="L2,tp0,i1" CDEF="s50,r50,10,9">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Common name</CHED>
                        <CHED H="1">Chemical abstracts name</CHED>
                        <CHED H="1">
                            Chemical
                            <LI>abstracts</LI>
                            <LI>No.</LI>
                        </CHED>
                        <CHED H="1">
                            Hazardous
                            <LI>waste No.</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">HFPO-DA</ENT>
                        <ENT>Hexafluoropropylene oxide-dimer acid</ENT>
                        <ENT>13252-13-6</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">HFPO-DA salts and enantiomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFBA</ENT>
                        <ENT>Perfluorobutanoic acid</ENT>
                        <ENT>375-22-4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFBA salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFBS</ENT>
                        <ENT>Perfluorobutanesulfonic acid</ENT>
                        <ENT>375-73-5</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFBS salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFDA</ENT>
                        <ENT>Perfluorodecanoic acid</ENT>
                        <ENT>335-76-2</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFDA salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFHxA</ENT>
                        <ENT>Perfluorohexanoic acid</ENT>
                        <ENT>307-24-4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFHxA salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFHxS</ENT>
                        <ENT>Perfluorohexanesulfonic acid</ENT>
                        <ENT>355-46-4</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFHxS salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFNA</ENT>
                        <ENT>Perfluorononanoic acid</ENT>
                        <ENT>375-95-1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFNA salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFOA</ENT>
                        <ENT>Perfluorooctanoic acid</ENT>
                        <ENT>335-67-1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFOA salts and structural isomers</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFOS</ENT>
                        <ENT>Perfluorooctanesulfonic acid</ENT>
                        <ENT>1763-23-1</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">PFOS salts and structural isomers</ENT>
                    </ROW>
                </GPOTABLE>
                <PART>
                    <HD SOURCE="HED">PART 271—REQUIREMENTS FOR AUTHORIZATION OF STATE HAZARDOUS WASTE PROGRAMS</HD>
                </PART>
                <AMDPAR>3. The authority citation for Part 271 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>42 U.S.C. 6905, 6912(a), 6926, and 6939g.</P>
                </AUTH>
                <AMDPAR>
                    4. Section 271.1(j) is amended by adding the following entry to Table 1
                    <FTREF/>
                     in chronological order by date of publication to read as follows.
                </AMDPAR>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         This listing implements HSWA only to the extent it applies to 40 CFR 264.101 and 270.14(d) and to 40 CFR Subpart S.
                    </P>
                </FTNT>
                <SECTION>
                    <SECTNO>§ 271.1</SECTNO>
                    <SUBJECT>Purpose and scope.</SUBJECT>
                    <P>(j) * * *</P>
                    <GPOTABLE COLS="4" OPTS="L1,i1" CDEF="s50,r50,r50,r50">
                        <TTITLE>Table 1—Regulations Implementing the Hazardous and Solid Waste Amendments of 1984</TTITLE>
                        <BOXHD>
                            <CHED H="1">Promulgation date</CHED>
                            <CHED H="1">Title of regulation</CHED>
                            <CHED H="1">Federal Register reference</CHED>
                            <CHED H="1">Effective date</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22"> </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="28">*         *         *         *         *         *         *</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">[DATE OF PUBLICATION OF FINAL RULE]</ENT>
                            <ENT O="xl">
                                Listing of certain PFAS.
                                <SU>6</SU>
                            </ENT>
                            <ENT>
                                [
                                <E T="02">FEDERAL REGISTER</E>
                                 PAGE NUMBERS FOR FINAL RULE]
                            </ENT>
                            <ENT>[EFFECTIVE DATE OF FINAL RULE]</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="28">*         *         *         *         *         *         *</ENT>
                        </ROW>
                    </GPOTABLE>
                    <PRTPAGE P="8621"/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02324 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Parts 271 and 272</CFR>
                <DEPDOC>[EPA-R08-RCRA-2023-0424; FRL 11356-02-R8]</DEPDOC>
                <SUBJECT>South Dakota: Authorization of State Hazardous Waste Management Program Revisions and Incorporation by Reference</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Environmental Protection Agency (EPA) is proposing to grant authorization to the State of South Dakota for the changes to its hazardous waste program under the Solid Waste Disposal Act, as amended, commonly referred to as the Resource Conservation and Recovery Act (RCRA). The EPA has determined that these changes satisfy all requirements needed to qualify for final authorization, and is authorizing the State's changes through a direct final action which can be found in the “Rules and Regulations” section of this 
                        <E T="04">Federal Register</E>
                        . In addition, the EPA is proposing to codify in the regulations entitled “Approved State Hazardous Waste Management Programs,” South Dakota's authorized hazardous waste program. The EPA will incorporate by reference into the Code of Federal Regulations (CFR) those provisions of the State regulations that are authorized and that the EPA will enforce under RCRA.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Send written comments by March 11, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, identified by Docket ID No. EPA-R08-RCRA-2023-0424 at 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the detailed instructions for submitting comments electronically or by other methods in the 
                        <E T="02">ADDRESSES</E>
                         section of the direct final rule located in the Rules section of this 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Moye Lin at (303) 312-6667, 
                        <E T="03">lin.moye@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In the “Rules and Regulations” section of this 
                    <E T="04">Federal Register</E>
                    , the EPA is authorizing changes to the South Dakota program, in addition to codifying and incorporating by reference the State's hazardous waste program as a direct final rule. The EPA did not make a proposal prior to the direct final rule because we believe these actions are not controversial and do not expect comments that oppose them. We have explained the reasons for this authorization and incorporation by reference in the preamble to the direct final rule.
                </P>
                <P>Unless EPA receives written comments that oppose the authorization and incorporation by reference during the comment period, the direct final rule will become effective on the date it establishes, and we will not take further action on this proposal. If we get comments that oppose the authorization, we will withdraw the direct final rule and it will not take immediate effect. We will then respond to public comments in a later final rule based on this proposal. You may not have another opportunity for comment. If you want to comment on this action, you must do so at this time.</P>
                <SIG>
                    <DATED>Dated: January 25, 2024.</DATED>
                    <NAME>KC Becker,</NAME>
                    <TITLE>Regional Administrator, Region 8.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02311 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Part 1</CFR>
                <DEPDOC>[WC Docket No. 21-341; Report No. 3208; FR ID 201128]</DEPDOC>
                <SUBJECT>Petitions for Reconsideration of Action in Rulemaking Proceeding; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Petition for reconsideration; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Federal Communications Commission corrects a Proposed rule published in the 
                        <E T="04">Federal Register</E>
                         of January 29, 2024, announcing the dates for filing oppositions and replies to a Petition for Reconsideration of Action in a Rulemaking Proceeding, adopted by the Commission on November 15, 2023. The document contained an error in the Dates section, the contact information, and the subject of the supplementary information.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>February 8, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For further information, please contact Melissa Droller Kirkel, Competition Policy Division, Wireline Competition Bureau, at 202-418-7958 or 
                        <E T="03">Melissa.Kirkel@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of January 29, 2024, in FR Doc. 2024-01632, on page 5451, the following corrections are made:
                </P>
                <HD SOURCE="HD1">Correction</HD>
                <P>
                    1. In the first column, last paragraph, correct the 
                    <E T="02">Dates</E>
                     caption to read:
                </P>
                <FP>
                    <E T="02">DATES:</E>
                     Oppositions to the Petitions must be filed on or before February 13, 2024. Replies to oppositions must be filed on or before February 23, 2024.
                </FP>
                <HD SOURCE="HD1">Correction</HD>
                <P>
                    2. In the second column, second paragraph from the top, correct the 
                    <E T="02">For Further Information Contact</E>
                     caption to read:
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For further information, please contact Melissa Droller Kirkel, Competition Policy Division, Wireline Competition Bureau, at 
                        <E T="03">Melissa.Kirkel@fcc.gov,</E>
                         202-418-7958.
                    </P>
                    <HD SOURCE="HD1">Correction</HD>
                    <P>
                        3. In the second column, fourth paragraph from the top, correct the 
                        <E T="02">Supplementary Information</E>
                         caption to read:
                    </P>
                    <P>
                        <E T="03">Subject:</E>
                         Protecting Consumers from SIM Swap and Port-out Fraud (WC Docket No. 21-341).
                    </P>
                    <SIG>
                        <FP>Federal Communications Commission.</FP>
                        <NAME>Marlene Dortch,</NAME>
                        <TITLE>Secretary.</TITLE>
                    </SIG>
                </FURINF>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02578 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Parts 2 and 30</CFR>
                <DEPDOC>[ET Docket No. 21-186; FCC 23-114; FR ID 200939]</DEPDOC>
                <SUBJECT>Modifying Emissions Limits for the 24.25-24.45 GHz and 24.75-25.25 GHz Bands; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In this document, the Commission is correcting the docket number in a proposed rule that appeared in the 
                        <E T="04">Federal Register</E>
                         on January 29, 2024. The document proposes to implement certain decisions regarding the 24.25-27.5 GHz band made in the World Radiocommunication Conference held by the International Telecommunication Union (ITU) in 2019 (WRC-19). Specifically, the Commission proposes to align part 30 of the Commission's rules for mobile operations with the Resolution 750 limits on unwanted emissions into the passive 23.6-24.0 GHz band that were adopted at WRC-19. These proposed rule changes would 
                        <PRTPAGE P="8622"/>
                        help to facilitate the protection of passive sensors used for weather forecasting and scientific research in the 23.6 GHz-24.0 GHz band, while continuing to promote flexible commercial use of the 24.25-24.45 GHz and 24.75-25.25 GHz bands (collectively, 24 GHz band). The Commission also seeks comment on alternatives to the proposals it makes, and on other related issues.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are due on or before February 28, 2024; reply comments are due on or before March 14, 2024. Written comments on the Initial Regulatory Flexibility Analysis (IRFA) in this document must have a separate and distinct heading designating them as responses to the IRFA and must be submitted by the public on or before February 28, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Simon Banyai of the Wireless Telecommunications Bureau, Broadband Division, at 202-418-1443 or 
                        <E T="03">Simon.Banyai@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Commission is correcting the Preamble and Regulatory Flexibility Act sections of proposed rule FR Doc. 2024-01681 by correcting the docket number.</P>
                <HD SOURCE="HD1">Correction</HD>
                <P>
                    In FR Doc. 2024-01681 appearing on page 5440 in the 
                    <E T="04">Federal Register</E>
                     of Monday, January 29, 2024, the following corrections are made:
                </P>
                <FP SOURCE="FP-1">ET Docket No. 21-186 [Corrected]</FP>
                <P>1. On page 5440, in the first column, in the Preamble, the Agency Docket Number is corrected to read as “[ET Docket No. 21-186; FCC 23-114; FR ID 198341]”.</P>
                <P>
                    2. On page 5440, in the third column, in 
                    <E T="02">SUPPLEMENTARY INFORMATION</E>
                    , the Regulatory Flexibility Act section is corrected to read as “The Commission seeks comment on potential rule and policy changes contained in the NPRM, and accordingly, has prepared an IRFA. The IRFA for this NPRM in ET Docket No. 21-186 is set forth below in this document and written public comments are requested. Comments must be filed by the deadlines for comments on the NPRM indicated under the 
                    <E T="02">DATES</E>
                     section of this document and must have a separate and distinct heading designating them as responses to the IRFA. The Commission reminds commenters to file in the appropriate docket: ET Docket No. 21-186.”
                </P>
                <SIG>
                    <FP>Federal Communications Commission</FP>
                    <NAME>Katura Jackson,</NAME>
                    <TITLE>Federal Register Liaison Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02598 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Part 73</CFR>
                <DEPDOC>[MB Docket No. 24-14; FCC 24-1; FR ID 198888]</DEPDOC>
                <SUBJECT>Priority Application Review for Broadcast Stations That Provide Local Journalism or Other Locally Originated Programming</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In this document, the Federal Communications Commission (Commission) issues a Notice of Proposed Rulemaking to prioritize processing review of certain applications filed by commercial and noncommercial radio and television broadcast stations that provide locally originated programming. The Commission's goal is to provide additional incentive to stations to provide programming that responds to the needs and interests of the communities they are licensed to serve. In 2017, the Commission eliminated the rule that required broadcast stations to maintain a main studio located in or near their community of license, as well as the associated requirement that the main studio have program origination capability. We propose this processing priority in order to further encourage radio and TV stations to serve their community of license with local journalism or other locally originated programming. Such prioritization would be granted to renewal applicants, as well as applicants for assignment or transfer of license, that certify they provide locally originated programming, thereby advancing our efforts to promote localism and serve local communities across the nation.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments may be filed on or before March 11, 2024, and reply comments may be filed on or before April 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments and reply comments, identified by MB Docket No. 24-14, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Electronic Filers:</E>
                         Comments may be filed electronically using the internet by accessing the ECFS: 
                        <E T="03">https://apps.fcc.gov/ecfs/</E>
                        .
                    </P>
                    <P>
                        • 
                        <E T="03">Paper Filers:</E>
                         Parties who choose to file by paper must file an original and one copy of each filing.
                    </P>
                    <P>• Filings can be sent by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail. All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission.</P>
                    <P>• Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail) must be sent to 9050 Junction Drive, Annapolis Junction, MD 20701.</P>
                    <P>• U.S. Postal Service first-class, Express, and Priority mail must be addressed to 45 L Street NE, Washington, DC 20554.</P>
                    <P>
                        • Effective March 19, 2020, and until further notice, the Commission no longer accepts any hand or messenger delivered filings. This is a temporary measure taken to help protect the health and safety of individuals, and to mitigate the transmission of COVID-19. See FCC Announces Closure of FCC Headquarters Open Window and Change in Hand-Delivery Policy, Public Notice, DA 20-304 (March 19, 2020). 
                        <E T="03">https://www.fcc.gov/document/fcc-closes-headquarters-open-window-and-changes-hand-delivery-policy</E>
                        .
                    </P>
                    <P>
                        <E T="03">People with Disabilities.</E>
                         To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an email to 
                        <E T="03">fcc504@fcc.gov</E>
                         or call the Consumer and Governmental Affairs Bureau at (202) 418-0530.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kim Matthews, Media Bureau, Policy Division, at (202) 418-2154, or by email at 
                        <E T="03">Kim.Matthews@fcc.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This is a summary of the Commission's Notice of Proposed Rulemaking (
                    <E T="03">NPRM</E>
                    ), in MB Docket No. 24-14; FCC 24-1, adopted on January 10, 2024 and released on January 17, 2024. The full text of this document is available for download at 
                    <E T="03">https://docs.fcc.gov/public/attachments/FCC-24-1A1.pdf</E>
                    .
                </P>
                <P>
                    To request materials in accessible formats (braille, large print, computer diskettes, or audio recordings), please send an email to 
                    <E T="03">FCC504@fcc.gov</E>
                     or call the Consumer &amp; Government Affairs Bureau at (202) 418-0530 (VOICE), (202) 418-0432 (TTY).
                </P>
                <HD SOURCE="HD1">Synopsis</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    1. One of a broadcaster's fundamental public service obligations is to provide programming that is responsive to the needs and interests of its community of license. The Communications Act requires the Commission to determine, in the case of applications for licenses, “whether the public interest, convenience, and necessity will be served by granting such application.” The Commission has consistently interpreted this requirement to mean that licensees must air programming 
                    <PRTPAGE P="8623"/>
                    that serves their local community. The main studio and local program origination rules were originally adopted to ensure that broadcast stations fulfill their local service obligations. In furtherance of section 307(b) of the Communications Act of 1934, as amended (the Act), which requires the Commission to “make such distribution of licenses, frequencies, hours of operation, and of power among the several States and communities as to provide for a fair, efficient, and equitable distribution of radio service to each of the same,” each broadcast radio and television station is assigned to a community of license that it is obligated to serve. The main studio rule required stations to maintain the main studio in or near its community of license to facilitate interaction between the station and the local community it is licensed to serve. The Commission also required that the main studio have a “meaningful management and staff presence” to fulfill the main studio's function, and that the main studio be equipped with production and transmission facilities.
                </P>
                <P>2. Locally originated programming was deemed an important element of a station's service obligations from the time location requirements for AM, FM, and TV broadcast stations were first adopted. As the main studio played a key role in the origination of a broadcast station's programming, its location in the community helped to ensure that the station could participate in community activities, that community members could participate in live programs, and that community residents could more easily present complaints or suggestions to the station. The Commission reasoned that interaction between the station and the community would help foster programming responsive to community needs and concerns.</P>
                <P>3. In 2017, however, the Commission eliminated the main studio rule and the associated requirements that the main studio have full-time management and staff present during normal business hours, and that it have program origination capability. The Commission found that technological changes have “rendered local studios unnecessary” as a means for viewers and listeners to contact or access their local station. The Commission noted that most community members communicate with stations via email, station websites, telephone, or other means, rather than visiting a main studio, and that public inspection files can now be viewed on the Commission's Online Public Inspection File (OPIF) database. The Commission also found that there was no evidence that the physical location of a station's main studio is the reason broadcasters are able to deliver content that meets the needs and interests of the local community.</P>
                <P>4. The elimination of the main studio rule and its associated requirements followed other, earlier steps taken by the Commission to reduce or eliminate regulations applicable to TV and radio broadcasters that were intended to reinforce the obligation of stations to provide programming responsive to community needs and interests. In its radio and television deregulation orders, the Commission eliminated its formal ascertainment and program log requirements and quantitative guidelines regarding the duration, type, and time of presentation of nonentertainment programming. While the Commission concluded generally that these requirements were no longer necessary or appropriate means to ensure station operation in the public interest, it reaffirmed the continuing obligation of all licensees to provide issue-responsive programming.</P>
                <P>5. Currently, the Commission requires stations to prepare quarterly a list of programs that “have provided the most significant treatment of community issues.” The purpose of this requirement is to provide both the public and the Commission with information needed to monitor a licensee's performance in meeting its public interest obligation of providing programming that is responsive to its community. Our current rules require full-power radio and TV and Class A TV broadcasters to post these issues/programs lists on the station's OPIF. Further, as part of the broadcast station license renewal process, the Commission is required to find that “the station has served the public interest, convenience, and necessity” during its preceding license term.</P>
                <HD SOURCE="HD1">II. Discussion</HD>
                <P>6. To provide an additional incentive to stations to broadcast content responsive to the needs of the local community, particularly news and information, we propose to adopt a change in our application processing procedures that would benefit those radio and TV broadcasters that certify that they provide locally originated content. Specifically, when reviewing applications for renewal, transfer, or assignment of license, we propose to adopt a processing policy to prioritize evaluation of those applications filed by stations that certify that they provide locally originated programming. These applications would be the first to be reviewed, which would likely result in quicker action and, if the application is granted, quicker approval of these applications.</P>
                <P>7. We tentatively conclude that our proposal to award priority application review to applicants that provide locally originated programming advances the Commission's longstanding policy goal of encouraging licensees to air programming that serves the needs and interests of their local community. We also tentatively conclude that the provision by a station of locally originated programming serves as a reasonable gauge of whether the station is serving the public interest by providing programming that is responsive to particular local needs. In addition, by focusing on where the programming is created, our proposal avoids having the Commission try to evaluate the content of a station's broadcasts to determine their local nature.</P>
                <P>8. The Commission has recognized that programming does not have to be locally originated to have interest or value to audiences in any particular community and has suggested that locally originated content may not always be responsive to a community's needs or interests. But the corollary that some may read into those statements—that locally originated programming is not valuable enough to warrant Commission attention—goes too far. To the contrary, programming containing at least some locally sourced content appears quite likely to be responsive to local concerns and interests. We believe that the incentives behind the creation of local programming (including but not limited to financial incentives) tend to align local creators with the needs and interests of local audiences; evidence suggests that creators of local programming would be unlikely to expend time and financial resources on material that has little or no appeal to local listeners and viewers. We also recognize that the line between “local” and “non-local” is not always a sharp one; broadcasters may “localize” a state, national, or international issue by providing local commentary or local expert explanations on the probable effect of the issue on people within the station's signal contour. Such content plainly also serves local needs and interests. We seek comment on these views.</P>
                <P>
                    9. Accordingly, to the degree that the Main Studio Elimination Order could be read to the contrary, we tentatively conclude that locally originated programming usually reflects needs, interests, circumstances, or perspectives that may be quite pertinent to that community and that production of local broadcast programming remains a key 
                    <PRTPAGE P="8624"/>
                    consideration. We also question whether the Main Studio Elimination Order's predictive judgment—that the Commission's action there would foster creation of more and better local content—has actually come to pass. We invite comment on these views and request commenters to provide analysis and data in support of their positions. Under our proposal, licensees will continue to ultimately have the discretion to determine what mix of local and non-local programming will best serve the community. We tentatively conclude our proposal does not interfere with this discretion but merely offers an opportunity to licensees to obtain prioritized review of applications if they certify that they provide programming that is locally originated. We invite comment generally on these views.
                </P>
                <HD SOURCE="HD2">A. Processing Priority</HD>
                <P>10. We tentatively conclude that our proposal would apply only to those applications for which processing is not immediately available because the application has a hold, petition to deny, or other pending issue that requires further staff review. Applications without holds or other processing issues requiring additional staff review, also referred to here as “simple” applications, would be acted upon consistent with current routine processing procedures. In contrast, applications that have holds related to the applicant's failure to comply with Commission rules, or where petitions to deny or informal objections have been filed, generally require additional staff research and processing time before they can be processed. The amount of time it takes to process these types of applications is often dependent upon the number of applications pending before the Commission at any given time, the complexity of the issues involved, and the availability of Commission staff to process the applications in light of other agency priorities. With respect to these more “complex” applications, we propose that the staff first would consider those that are filed together with a certification that the station provides programming that is locally originated. We tentatively conclude this approach will not slow the review of “simple” applications that are otherwise grantable but will create a priority system for more “complex” applications that require further staff attention. We will not delay the processing of a “simple” application while a more “complex” application with a certification is pending. We seek comment on this approach.</P>
                <P>11. We propose that the decision by a licensee to elect to certify that the station meets the local programming guideline be purely voluntary, and we seek comment on this proposal. With respect to those licensees that either cannot, or choose not, to provide a certification, the Commission staff will process the licensee's application pursuant to its normal procedures. Applications that do not include a certification will not be scrutinized or processed differently as a substantive matter than applications with a certification, other than the prioritization proposal discussed above.  </P>
                <P>12. While we do not propose at this time to extend our proposed application processing priority to modification applications, waiver requests, or requests for Special Temporary Authority (STA), we invite comment on whether these types of applications and requests should be included in our proposal herein. Based upon the experience of the Media's Bureaus licensing divisions, we note that the review time for these applications is generally more abbreviated than for renewals and transactions, and therefore such a prioritization may not be appreciably relevant. Despite this, should these, or other, kind of requests be treated in the same manner as renewal applications and applications for assignment and transfer of control for purposes of application processing priority?</P>
                <P>
                    13. Finally, we do not propose to offer priority application review, as outlined herein, to applications filed for radio translators or boosters or TV translators. Booster stations do not originate programming and translator stations may only originate a very limited amount of programming so the underlying purpose of the proposed processing policy—
                    <E T="03">i.e.,</E>
                     to further incentivize broadcast licensees to serve community needs and interests through production of locally originated programming—would not apply. Accordingly, we believe there would be minimal value, if any, in asking these stations to certify they provide locally originated programming content. As noted above, we tentatively conclude this approach will not slow the review of “simple” applications that are otherwise grantable. We seek comment on our proposals and findings.
                </P>
                <HD SOURCE="HD2">B. Applications Eligible for Processing Priority</HD>
                <HD SOURCE="HD3">1. “Local” Market</HD>
                <P>14. Under our proposal, we would prioritize the review of applications filed by stations that provide locally originated programming. We invite comment on how we should define “local” for this purpose. The former main studio rule required each AM, FM, and television broadcast station to maintain a main studio that is located either: “(1) [w]ithin the station's community of license; (2) [a]t any location within the principal community contour of any AM, FM, or TV broadcast station licensed to the station's community of license; or (3) [w]ithin twenty-five miles from the reference coordinates of the center of its community of license as described in § 73.208(a)(1).” Should we define “locally originated” programing as programming originated within one or more of these geographic areas? One purpose of the former main studio rule was to ensure that the station complied with its local service obligations. Would adopting a definition of the geographic area in which “locally originated ” programming is created for purposes of priority application review in a manner similar to the geographic area used for the former main studio rule help ensure that this programming reflects the needs and interests of the local community? Should we instead define the “local” market as the station's service contour? As service contours generally encompass a larger geographic area than a station's community of license or principal community contour, this definition would give the station more flexibility with respect to where local programming could be originated. We invite comment generally on how to define the geographic area in which a program should be originated in order to qualify as “local” under our proposal herein. Should we define the local market differently for radio stations than for TV stations? Should we define the local market differently for low power TV stations than full power TV stations?</P>
                <HD SOURCE="HD3">2. Locally “Originated” Programming</HD>
                <P>
                    15. We also invite comment on how to define programming “originated” locally for purposes of qualifying for priority application review. We propose that any kind of activity involved in creating audio (radio) or video (TV) programming that occurs within the “local” market, as defined in this proceeding, would be sufficient. Local program origination could involve, for example, activities such as program scripting, recording (video or audio) at a studio or other location in the local market, or editing. Our proposed approach would include programming that contains video or audio recordings that were made at locations outside the local market, as long as the program also includes some other element of local 
                    <PRTPAGE P="8625"/>
                    creation. For particular programming that contains content made at locations outside the local market, should we establish a minimum amount of required locally originated programming? What other kinds of local activities should qualify as local program origination?
                </P>
                <P>16. We note that, in the case of mutually exclusive applications for new Low Power FM (LPFM) stations, the Commission's rules favor the selection of applicants that pledge to provide at least eight hours of locally originated programming each day. The LPFM rules define “local origination” as “the production of programming by the licensee within ten miles of the coordinates of the proposed transmitting antenna” and provides the following examples of locally originated programming: “licensee produced call-in shows, music selected and played by a disc jockey present on site, broadcasts of events at local schools, and broadcasts of musical performances at a local studio or festival, whether recorded or live.” We propose that these kinds of programs and activities would qualify as locally originated programming for purposes of our proposed priority application review, and invite comment on this proposal. Are there other examples of locally originated programming we should provide?</P>
                <P>17. We note that, in the LPFM context for resolving mutually exclusive applications, the rules require the locally originated programming to be produced by the licensee. We do not propose to adopt a similar requirement for this priority application review proposal. Thus, we propose that the locally originated content can be produced by a third party that is not the licensee. We invite comment on this approach.</P>
                <P>18. The LPFM rules further provide that local origination “does not include the broadcast of repetitive or automated programs or time-shifted recordings of non-local programming whatever its source.” Should we exclude these kinds of programs and/or time-shifted recordings from the definition of local programming for purposes of priority application review? In addition, the LPFM rules provide that “local origination does not include a local program that has been broadcast twice, even if the licensee broadcasts the program on a different day or makes small variations in the program thereafter.” In adopting this restriction for LPFM, the Commission noted that local origination is a “central virtue” of that service and that there was “room for abuse” if repetitious, automated programs could count as locally originated. Should we adopt this same restriction on repetition of locally originated programming for purposes of priority application review? With respect to television stations, should we define “locally originated programming” for purposes of priority application review as programming containing simultaneous video and audio programming where the audio portion of the programming directly relates to the video portion of the program? This would mean that, for television applicants, video-only or audio-only programming would not count for purposes of obtaining priority application review. For television stations, would this restriction help ensure that locally originated programming contains the type of television services viewers expect TV stations to provide?</P>
                <HD SOURCE="HD2">C. Certification</HD>
                <P>19. We propose to provide priority staff review to licensees that certify that the station(s) provides on average at least three hours per week of locally originated programming. We note that, to be eligible for Class A status, the CBPA required that low power TV stations, during the 90 days preceding the date of enactment of the statute, broadcast an average of at least three hours per week of programming produced within the “market area” served by the station. Should we adopt the same three-hour guideline for purposes of priority staff review? We note that under a three-hour per week criteria, stations on the air 24 hours per day seven days each week that air locally originated programming for just two minutes at the top of each hour would exceed a three-hour guideline. Should the guideline number be greater or less than three hours? Should it be prorated for stations that are on the air less than 24 hours per day? Should the amount be the same for radio and television stations? Should it be the same for commercial and non-commercial stations? Should applicants be required to have met the required amount of hours per week for a minimum number of days or weeks prior to filing of the application? If so, what would be an appropriate minimum number of days or weeks? As in the CBPA, would 90 days prior to the filing of the application be an appropriate timeframe? Should applicants also be required to continue to meet the required amount of hours per week while the subject application is pending? Should applicants be required to re-certify compliance while the application is pending? Should applicants also be required to continue to meet the required amount of hours per week for a minimum number of days or weeks after the application is granted? If so, what would be an appropriate minimum number of days or weeks?</P>
                <P>
                    20. We propose that the Media Bureau add a question to each FCC application form for which expedited processing would be made available (
                    <E T="03">e.g.,</E>
                     each TV/radio renewal, transfer, and assignment application form) asking the licensee whether it certifies, under penalty of perjury, that the station(s) provides at least three hours per week of locally originated programming, consistent with the criteria adopted in this proceeding. We invite comment on this approach. We propose that, in the case of applications involving multiple stations (such as an application proposing the transfer or assignment of multiple stations), priority review be available only if the applicant certifies that every station included in the application meets the priority processing criteria, and invite comment on this proposal. Should we require the applicant to provide any additional information that would permit the Commission to review the certification, such as identifying the programs the applicant claims are locally originated?
                </P>
                <HD SOURCE="HD2">D. Digital Equity and Inclusion</HD>
                <P>21. Finally, the Commission, as part of its continuing effort to advance digital equity for all, including people of color, persons with disabilities, persons who live in rural or Tribal areas, and others who are or have been historically underserved, marginalized, or adversely affected by persistent poverty or inequality, invites comment on any equity-related considerations and benefits (if any) that may be associated with the proposals and issues discussed herein. Specifically, we seek comment on how our proposals may promote or inhibit advances in diversity, equity, inclusion, and accessibility, as well the scope of the Commission's relevant legal authority.</P>
                <HD SOURCE="HD1">III. Procedural Matters</HD>
                <P>
                    22. 
                    <E T="03">Ex Parte Rules—Permit-But-Disclose.</E>
                     The proceeding this 
                    <E T="03">NPRM</E>
                     initiates shall be treated as a “permit-but-disclose” proceeding in accordance with the Commission's ex parte rules. Persons making 
                    <E T="03">ex parte</E>
                     presentations must file a copy of any written presentation or a memorandum summarizing any oral presentation within two business days after the presentation (unless a different deadline applicable to the Sunshine period applies). Persons making oral 
                    <E T="03">ex parte</E>
                      
                    <PRTPAGE P="8626"/>
                    presentations are reminded that memoranda summarizing the presentation must (1) list all persons attending or otherwise participating in the meeting at which the 
                    <E T="03">ex parte</E>
                     presentation was made, and (2) summarize all data presented and arguments made during the presentation. If the presentation consisted in whole or in part of the presentation of data or arguments already reflected in the presenter's written comments, memoranda, or other filings in the proceeding, the presenter may provide citations to such data or arguments in his or her prior comments, memoranda, or other filings (specifying the relevant page and/or paragraph numbers where such data or arguments can be found) in lieu of summarizing them in the memorandum. Documents shown or given to Commission staff during 
                    <E T="03">ex parte</E>
                     meetings are deemed to be written ex parte presentations and must be filed consistent with rule 1.1206(b). In proceedings governed by rule 1.49(f) or for which the Commission has made available a method of electronic filing, written 
                    <E T="03">ex parte</E>
                     presentations and memoranda summarizing oral 
                    <E T="03">ex parte</E>
                     presentations, and all attachments thereto, must be filed through the electronic comment filing system available for that proceeding, and must be filed in their native format (
                    <E T="03">e.g.,</E>
                     .doc, .xml, .ppt, searchable .pdf). Participants in this proceeding should familiarize themselves with the Commission's ex parte rules.
                </P>
                <P>
                    23. 
                    <E T="03">Filing Requirements—Comments and Replies.</E>
                     Pursuant to §§ 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments may be filed using the Commission's Electronic Comment Filing System (ECFS). 
                    <E T="03">See</E>
                     Electronic Filing of Documents in Rulemaking Proceedings, 63 FR 24121 (1998).
                </P>
                <P>24. During the time the Commission's building is closed to the general public and until further notice, if more than one docket or rulemaking number appears in the caption of a proceeding, paper filers need not submit two additional copies for each additional docket or rulemaking number; an original and one copy are sufficient.</P>
                <P>
                    25. 
                    <E T="03">Regulatory Flexibility Act.</E>
                     The Regulatory Flexibility Act of 1980, as amended (RFA), requires that an agency prepare a regulatory flexibility analysis for notice and comment rulemakings, unless the agency certifies that “the rule will not, if promulgated, have a significant economic impact on a substantial number of small entities.” Accordingly, we have prepared an Initial Regulatory Flexibility Analysis (IRFA) concerning the possible impact of the rule changes proposed in this 
                    <E T="03">NPRM</E>
                     on small entities. Written public comments are requested on the IRFA. Comments must be filed by the deadlines for comments on the 
                    <E T="03">NPRM</E>
                     indicated on the first page of this document and must have a separate and distinct heading designating them as responses to the IRFA.
                </P>
                <P>
                    26. 
                    <E T="03">Providing Accountability Through Transparency Act.</E>
                     The Providing Accountability Through Transparency Act requires each agency, in providing notice of a rulemaking, to post online a brief plain-language summary of the proposed rule. Accordingly, the Commission will publish the required summary of this Notice of Proposed Rulemaking/Further Notice of Proposed Rulemaking on 
                    <E T="03">https://www.fcc.gov/proposed-rulemakings.</E>
                </P>
                <HD SOURCE="HD1">IV. Paperwork Reduction Act</HD>
                <P>
                    27. This document proposes new or modified information collection requirements. The Commission, as part of its continuing effort to reduce paperwork burdens and pursuant to the Paperwork Reduction Act of 1995, Public Law 104-13, invites the general public and the Office of Management and Budget (OMB) to comment on these information collection requirements. In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, 
                    <E T="03">see</E>
                     44 U.S.C. 3506(c)(4), we seek specific comment on how we might further reduce the information collection burden for small business concerns with fewer than 25 employees.
                </P>
                <HD SOURCE="HD1">V. Initial Regulatory Flexibility Analysis</HD>
                <P>
                    28. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), the Commission has prepared this Initial Regulatory Flexibility Analysis (IRFA) concerning the possible significant economic impact on small entities by the policies and rules proposed in the Notice of Proposed Rulemaking (
                    <E T="03">NPRM</E>
                    ). Written public comments are requested on this IRFA. Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments provided on the first page of the 
                    <E T="03">NPRM.</E>
                     The Commission will send a copy of the NPRM, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). In addition, the NPRM and IRFA (or summaries thereof) will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <HD SOURCE="HD2">A. Need for, and Objectives of, the Proposed Rules</HD>
                <P>
                    29. In this 
                    <E T="03">NPRM,</E>
                     we propose to prioritize processing review of certain applications filed by commercial and noncommercial radio and television broadcast stations that provide locally originated programming. Our goal is to provide additional incentive to stations to provide programming that responds to the needs and interests of the communities they are licensed to serve. In 2017, the Commission eliminated the rule that required broadcast stations to maintain a main studio located in or near their community of license, as well as the associated requirement that the main studio have program origination capability. We propose this processing priority in order to further encourage radio and TV stations to serve their community of license with local journalism or other locally originated programming. Such prioritization would be granted to renewal applicants, as well as applicants for assignment or transfer of license, that certify they provide locally originated programming, thereby advancing our efforts to promote localism and serve local communities across the nation.
                </P>
                <P>
                    30. The 
                    <E T="03">NPRM</E>
                     also seeks comment on the Commission's proposal to exclude television translator and radio translator and booster stations from the proposed priority application review proposal and on whether its proposals may promote or inhibit advances in diversity, equity, inclusion, and accessibility, as well as the scope of the Commission's relevant legal authority.
                </P>
                <HD SOURCE="HD2">B. Legal Basis</HD>
                <P>31. The proposed action is authorized pursuant to sections 1, 2, 4(i), 4(j), 303, 307, and 309 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 152, 154(i), 154(j), 303, 307, and 309.</P>
                <HD SOURCE="HD2">C. Description and Estimate of the Number of Small Entities to Which the Proposed Rules Will Apply</HD>
                <P>
                    32. The RFA directs agencies to provide a description of, and where feasible, an estimate of the number of small entities that may be affected by the proposed rules, if adopted. The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act. A small business concern is one which: (1) is independently owned and operated; (2) is not dominant in its field of operation; 
                    <PRTPAGE P="8627"/>
                    and (3) satisfies any additional criteria established by the SBA.
                </P>
                <P>
                    33. 
                    <E T="03">Small Businesses, Small Organizations, Small Governmental Jurisdictions.</E>
                     Our actions, over time, may affect small entities that are not easily categorized at present. We therefore describe, at the outset, three broad groups of small entities that could be directly affected herein. First, while there are industry specific size standards for small businesses that are used in the regulatory flexibility analysis, according to data from the SBA'sOffice of Advocacy, in general a small business is an independent business having fewer than 500 employees. These types of small businesses represent 99.9% of all businesses in the United States, which translates to 33.2 million businesses.
                </P>
                <P>34. Next, the type of small entity described as a “small organization” is generally “any not-for-profit enterprise which is independently owned and operated and is not dominant in its field.” The Internal Revenue Service (IRS) uses a revenue benchmark of $50,000 or less to delineate its annual electronic filing requirements for small exempt organizations. Nationwide, for tax year 2020, there were approximately 447,689 small exempt organizations in the U.S. reporting revenues of $50,000 or less according to the registration and tax data for exempt organizations available from the IRS.</P>
                <P>35. Finally, the small entity described as a “small governmental jurisdiction” is defined generally as “governments of cities, counties, towns, townships, villages, school districts, or special districts, with a population of less than fifty thousand.” U.S. Census Bureau data from the 2017 Census of Governments indicate there were 90,075 local governmental jurisdictions consisting of general purpose governments and special purpose governments in the United States. Of this number, there were 36,931 general purpose governments (county, municipal, and town or township) with populations of less than 50,000 and 12,040 special purpose governments—independent school districts with enrollment populations of less than 50,000. Accordingly, based on the 2017 U.S. Census of Governments data, we estimate that at least 48,971 entities fall into the category of “small governmental jurisdictions.”</P>
                <P>
                    36. 
                    <E T="03">Television Broadcasting.</E>
                     This industry is comprised of “establishments primarily engaged in broadcasting images together with sound.” These establishments operate television broadcast studios and facilities for the programming and transmission of programs to the public. These establishments also produce or transmit visual programming to affiliated broadcast television stations, which in turn broadcast the programs to the public on a predetermined schedule. Programming may originate in their own studio, from an affiliated network, or from external sources. The SBA small business size standard for this industry classifies businesses having $41.5 million or less in annual receipts as small. 2017 U.S. Census Bureau data indicate that 744 firms in this industry operated for the entire year. Of that number, 657 firms had revenue of less than $25,000,000. Based on this data we estimate that the majority of television broadcasters are small entities under the SBA small business size standard.
                </P>
                <P>37. As of March 31, 2023, there were 1,375 licensed commercial television stations. Of this total, 1,282 stations (or 93.2%) had revenues of $41.5 million or less in 2021, according to Commission staff review of the BIA Kelsey Media Access Pro Television Database (BIA) on April 7, 2023, and therefore these licensees qualify as small entities under the SBA definition. In addition, the Commission estimates as of March 31, 2023, there were 383 licensed noncommercial educational (NCE) television stations, 381 Class A TV stations, and 1,887 LPTV stations. The Commission, however, does not compile and otherwise does not have access to financial information for these television broadcast stations that would permit it to determine how many of these stations qualify as small entities under the SBA small business size standard. Nevertheless, given the SBA's large annual receipts threshold for this industry and the nature of these television station licensees, we presume that all of these entities qualify as small entities under the above SBA small business size standard.</P>
                <P>
                    38. 
                    <E T="03">Radio Broadcasting.</E>
                     This industry is comprised of “establishments primarily engaged in broadcasting aural programs by radio to the public.” Programming may originate in the station's own studio, from an affiliated network, or from external sources. The SBA small business size standard for this industry classifies firms having $41.5 million or less in annual receipts as small. U.S. Census Bureau data for 2017 show that 2,963 firms operated in this industry during that year. Of this number, 1,879 firms operated with revenue of less than $25 million per year. Based on this data and the SBA's small business size standard, we estimate a majority of such entities are small entities.
                </P>
                <P>39. The Commission has estimated the number of licensed commercial radio stations to be 11,153 (4,472 commercial AM stations and 6,681 commercial FM stations). Of this total, 11,151 stations (or 99.98%) had revenues of $41.5 million or less in 2022, according to Commission staff review of the BIA Kelsey Inc. Media Access Pro Database (BIA) on April 7, 2023, and therefore these licensees qualify as small entities under the SBA definition. In addition, the Commission estimates that as of March 31, 2023, the number of licensed noncommercial radio stations to be 4,219, and the number of LPFM Stations to be 1,999. The Commission however does not compile, and otherwise does not have access to financial information for these radio stations that would permit it to determine how many of these stations qualify as small entities under the SBA small business size standard. Nevertheless, given the SBA's large annual receipts threshold for this industry and the nature of radio station licensees, we presume that all of these entities qualify as small entities under the above SBA small business size standard.</P>
                <P>40. We note that in assessing whether a business entity qualifies as small under the above definition, business control affiliations must be included. This estimate, therefore, likely overstates the number of small entities that might be affected, because the revenue figure on which it is based does not include or aggregate revenues from affiliated companies. In addition, another element of the definition of “small business” is that the entity not be dominant in its field of operation. The Commission is unable at this time to define or quantify the criteria that would establish whether a specific radio station is dominant in its field of operation. Accordingly, the estimate of small businesses to which rules may apply does not exclude any radio station from the definition of a small business on this basis and therefore may be over-inclusive to that extent. Also, an additional element of the definition of “small business” is that the entity must be independently owned and operated. The Commission notes that it is difficult at times to assess these criteria in the context of media entities and the estimates of small businesses to which they apply may be over-inclusive to this extent.</P>
                <HD SOURCE="HD2">D. Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements for Small Entities</HD>
                <P>
                    41. We expect that the proposed rules set forth in the 
                    <E T="03">NPRM</E>
                     will impose new 
                    <PRTPAGE P="8628"/>
                    or additional filing, recordkeeping and reporting requirements for small and other entities. We note, however, that while the proposed rules will create additional compliance requirements, the 
                    <E T="03">NPRM</E>
                     also proposes that the decision by a licensee to elect to certify that the station meets the local programming guideline be purely voluntary. With respect to those small or other licensees that either cannot, or choose not, to provide a certification, the Commission staff will process the licensee's application pursuant to its normal procedures.
                </P>
                <P>
                    42. The 
                    <E T="03">NPRM</E>
                     proposes to provide priority in terms of processing review to applications filed by commercial and noncommercial radio and television broadcast stations that certify that they provide on average at least three hours per week of locally originated programming. The 
                    <E T="03">NPRM</E>
                     also seeks comment on whether applicants should also be required to re-certify compliance while the subject application is pending, and whether they should be required to continue to meet the required amount of hours per week for a minimum number of days or weeks after the application is granted. We propose that the Media Bureau add a question to each FCC application form for which expedited processing would be made available (
                    <E T="03">e.g.,</E>
                     each TV/radio renewal, transfer, and assignment application form) asking the licensee whether it certifies, under penalty of perjury, that the station(s) provides at least three hours per week of locally originated programming, consistent with the criteria adopted in this proceeding. We also propose that, in the case of applications involving multiple stations, priority review be available only if the applicant certifies that every station included in the application meets the priority processing criteria. We invite comment on these proposals. We also seek comment on whether we should require applicants to provide any additional information that would permit the Commission to review the certification, such as identifying the programs the applicant claims are locally originated.
                </P>
                <P>
                    43. We propose that licensees that request priority staff review of an application(s) be required to certify, under penalty of perjury, that the station meets the criteria adopted in this proceeding. The 
                    <E T="03">NPRM</E>
                     seeks comment on whether we should require applicants to provide any additional information that would permit the Commission to review the certification, such as identifying the programs the applicant claims are locally originated. We expect that the information we receive in the comments will help the Commission identify and evaluate relevant compliance matters for small entities, including compliance costs and other burdens that may emerge as a result of the potential changes discussed in the 
                    <E T="03">NPRM.</E>
                </P>
                <HD SOURCE="HD2">E. Steps Taken To Minimize Significant Economic Impact on Small Entities and Significant Alternatives Considered</HD>
                <P>44. The RFA requires an agency to describe any significant, specifically small business, alternatives that it has considered in reaching its proposed approach, which may include the following four alternatives (among others): “(1) the establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance and reporting requirements under the rule for such small entities; (3) the use of performance, rather than design standards; and (4) an exemption from coverage of the rule, or any part thereof, for such small entities.”</P>
                <P>
                    45. The 
                    <E T="03">NPRM</E>
                     seeks comment generally on its proposal to provide priority staff review of applications filed by stations that certify that they provide an average of at least three hours per week of locally originated programming. The 
                    <E T="03">NPRM</E>
                     invites comment on whether this guideline is appropriate. We also invite comment on all the proposed approaches and on any alternatives, which will provide the Commission additional information on possible steps that can be taken to minimize any significant impact on small entities.
                </P>
                <P>
                    46. In an effort to minimize significant economic impact on small entities as a result of the proposals that are ultimately adopted, the 
                    <E T="03">NPRM</E>
                     makes clear that a station's participation in certifying that it meets the qualifications for priority application review is purely voluntary. A station may choose whether it wants to provide the additional information to qualify for prioritized review of its application and, should it decline to, would have its application processed pursuant to its normal procedures. Applications that do not include a certification will not be scrutinized or processed differently as a substantive matter than applications with a certification, other than the prioritization proposal discussed in the 
                    <E T="03">NPRM.</E>
                </P>
                <P>
                    47. Finally, we do not propose to offer priority application review, as outlined herein, to applications filed for radio translators or boosters or TV translators. Booster stations do not originate programming and translator stations may only originate a very limited amount of programming so the underlying purpose of the proposed processing policy—
                    <E T="03">i.e.,</E>
                     to further incentivize broadcast licensees to serve community needs and interests through production of locally originated programming—would not apply. Accordingly, we believe there would be minimal value, if any, in asking these stations to certify they provide locally originated programming. We tentatively conclude that our prioritized processing approach will not slow the review of “simple” applications that are otherwise grantable.
                </P>
                <HD SOURCE="HD2">F. Federal Rules That May Duplicate, Overlap, or Conflict With the Proposed Rules</HD>
                <P>48. None.</P>
                <HD SOURCE="HD1">VI. Ordering Clauses</HD>
                <P>
                    49. Accordingly, 
                    <E T="03">it is ordered</E>
                     that, pursuant to the authority found in sections 1, 2, 4(i), 4(j), 303, 307, and 309 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 152, 154(i), 154(j), 303, 307, and 309, this Notice of Proposed Rulemaking 
                    <E T="03">is adopted</E>
                    .
                </P>
                <P>
                    50. 
                    <E T="03">It is further ordered</E>
                     that the Office of the Secretary, Reference Information Center, 
                    <E T="03">shall send</E>
                     a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory Flexibility Act Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 47 CFR Part 73</HD>
                    <P>Television.</P>
                </LSTSUB>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Marlene Dortch,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Proposed Rules</HD>
                <P>For the reasons discussed in the preamble, the Federal Communications Commission proposes to amend 47 CFR part 73 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 73—RADIO BROADCAST SERVICES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 73 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 47 U.S.C. 154, 155, 301, 303, 307, 309, 310, 334, 336, 339.</P>
                </AUTH>
                <AMDPAR>2. Section 73.3514 is amended by adding paragraph (c) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 73.3514</SECTNO>
                    <SUBJECT> Content of applications.</SUBJECT>
                    <STARS/>
                    <P>
                        (c) Applicants for renewal, assignment, or transfer of license for commercial and noncommercial AM, FM, and TV broadcast stations may request priority staff review of such applications if the applicant certifies 
                        <PRTPAGE P="8629"/>
                        that the station provides an average of at least three hours per week of locally originated programming. This paragraph does not apply to TV translator or radio translator or booster stations.
                    </P>
                    <P>(1) For purposes of this provision, locally originated programming is programming produced either</P>
                    <P>(i) [W]ithin the station's community of license;</P>
                    <P>(ii) [A]t any location within the principal community contour of any AM, FM, or TV broadcast station licensed to the station's community of license; or</P>
                    <P>(iii) [W]ithin 25 miles from the reference coordinates of the center of its community of license as described in § 73.208(a)(1).</P>
                    <P>(2) For purposes of this provision, locally originated programming is defined as:</P>
                    <P>(i) Programming that was created within the area defined in paragraph (c)(1) of this section. Programming that contains video or audio recordings that were made at locations outside the area defined in paragraph (c)(1) of this section qualifies as locally originated programming as long as the program also includes some other element of local creation that takes place in the area defined in paragraph (c)(1) of this section, including program scripting, recording (video or audio) at a studio or other location in the local market, editing, or other activity.</P>
                    <P>(ii) Locally originated programming does not include: the broadcast of repetitive or automated programs or time-shifted recordings of non-local programming whatever its source; a local program that has been broadcast twice, even if the licensee broadcasts the program on a different day or makes small variations in the program thereafter. In addition, with respect to television stations, locally originated programming is programming containing simultaneous video and audio programming where the audio portion of the programming directly relates to the video portion of the program.</P>
                    <STARS/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02039 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Fish and Wildlife Service</SUBAGY>
                <CFR>50 CFR Part 17</CFR>
                <DEPDOC>[Docket No. FWS-R8-ES-2023-0261; FF09E21000 FXES1111090FEDR 245]</DEPDOC>
                <SUBJECT>Endangered and Threatened Wildlife and Plants; 90-Day Finding for the Kings River Pyrg</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notification of petition finding and initiation of status review.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        We, the U.S. Fish and Wildlife Service (Service), announce a 90-day finding on a petition to add the Kings River pyrg (
                        <E T="03">Pyrgulopsis imperialis</E>
                        ) to the List of Endangered and Threatened Wildlife under the Endangered Species Act of 1973, as amended (Act). Based on our review, we find that the petition to list the Kings River pyrg presents substantial scientific or commercial information indicating that the petitioned action may be warranted. Therefore, with the publication of this document, we announce that we are initiating a status review to determine whether the petitioned action is warranted. To ensure that the status review is comprehensive, we request scientific and commercial data and other information regarding Kings River pyrg and factors that may affect its status. Based on the status review, we will issue a 12-month petition finding, which will address whether or not the petitioned action is warranted, in accordance with the Act.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This finding was made on February 8, 2024. As we commence our status review, we seek any new information concerning the status of, or threats to, the Kings River pyrg or its habitats. Any information we receive during the course of our status review will be considered.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P/>
                    <P>
                        <E T="03">Supporting documents:</E>
                         A summary of the basis for the petition finding contained in this document is available on 
                        <E T="03">https://www.regulations.gov</E>
                         in Docket No. FWS-R8-ES-2023-0261. In addition, this supporting information is available by contacting the appropriate person, as specified in 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                        .
                    </P>
                    <P>
                        <E T="03">Status reviews:</E>
                         If you have new scientific or commercial data or other information concerning the status of, or threats to, the Kings River pyrg or its habitat, please provide those data or information by one of the following methods:
                    </P>
                    <P>
                        (1) 
                        <E T="03">Electronically:</E>
                         Go to the Federal eRulemaking Portal: 
                        <E T="03">https://www.regulations.gov.</E>
                         In the Search box, enter FWS-R8-ES-2023-0261, which is the docket number for this action. Then, click on the “Search” button. After finding the correct document, you may submit information by clicking on “Comment.” If your information will fit in the provided comment box, please use this feature of 
                        <E T="03">https://www.regulations.gov,</E>
                         as it is most compatible with our information review procedures. If you attach your information as a separate document, our preferred file format is Microsoft Word. If you attach multiple comments (such as form letters), our preferred format is a spreadsheet in Microsoft Excel.
                    </P>
                    <P>
                        (2) 
                        <E T="03">By hard copy:</E>
                         Submit by U.S. mail to: Public Comments Processing, Attn: FWS-R8-ES-2023-0261, U.S. Fish and Wildlife Service, MS: PRB/3W, 5275 Leesburg Pike, Falls Church, VA 22041-3803.
                    </P>
                    <P>
                        We request that you send information only by the methods described above. We will post all information we receive on 
                        <E T="03">https://www.regulations.gov.</E>
                         This generally means that we will post any personal information you provide us.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Justin Barrett, Deputy Field Supervisor, Reno Fish and Wildlife Office, telephone: 775-861-6300, email: 
                        <E T="03">justin_barrett@fws.gov.</E>
                         Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point-of-contact in the United States.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    Section 4 of the Act (16 U.S.C. 1533) and its implementing regulations in title 50 of the Code of Federal Regulations (50 CFR part 424) set forth the procedures for adding species to, removing species from, or reclassifying species on the Federal Lists of Endangered and Threatened Wildlife and Plants (Lists or List) in 50 CFR part 17. Section 4(b)(3)(A) of the Act requires that we make a finding on whether a petition to add a species to the List (
                    <E T="03">i.e.,</E>
                     “list” a species), remove a species from the List (
                    <E T="03">i.e.,</E>
                     “delist” a species), or change a listed species' status from endangered to threatened or from threatened to endangered (
                    <E T="03">i.e.,</E>
                     “reclassify” a species) presents substantial scientific or commercial 
                    <PRTPAGE P="8630"/>
                    information indicating that the petitioned action may be warranted. To the maximum extent practicable, we are to make this finding within 90 days of our receipt of the petition and publish the finding promptly in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <P>Our regulations establish that substantial scientific or commercial information with regard to a 90-day petition finding refers to credible scientific or commercial information in support of the petition's claims such that a reasonable person conducting an impartial scientific review would conclude that the action proposed in the petition may be warranted (50 CFR 424.14(h)(1)(i)). A positive 90-day petition finding does not indicate that the petitioned action is warranted; the finding indicates only that the petitioned action may be warranted and that a full review should occur.</P>
                <P>A species may be determined to be an endangered species or a threatened species because of one or more of the five factors described in section 4(a)(1) of the Act (16 U.S.C. 1533(a)(1)). The five factors are:</P>
                <P>(a) The present or threatened destruction, modification, or curtailment of its habitat or range (Factor A);</P>
                <P>(b) Overutilization for commercial, recreational, scientific, or educational purposes (Factor B);</P>
                <P>(c) Disease or predation (Factor C);</P>
                <P>(d) The inadequacy of existing regulatory mechanisms (Factor D); and</P>
                <P>(e) Other natural or manmade factors affecting its continued existence (Factor E).</P>
                <P>These factors represent broad categories of natural or human-caused actions or conditions that could have an effect on a species' continued existence. In evaluating these actions and conditions, we look for those that may have a negative effect on individuals of the species, as well as other actions or conditions that may ameliorate any negative effects or may have positive effects.</P>
                <P>We use the term “threat” to refer in general to actions or conditions that are known to, or are reasonably likely to, affect individuals of a species negatively. The term “threat” includes actions or conditions that have a direct impact on individuals (direct impacts), as well as those that affect individuals through alteration of their habitat or required resources (stressors). The term “threat” may encompass—either together or separately—the source of the action or condition, or the action or condition itself. However, the mere identification of any threat(s) may not be sufficient to compel a finding that the information in the petition is substantial information indicating that the petitioned action may be warranted. The information presented in the petition must include evidence sufficient to suggest that these threats may be affecting the species to the point that the species may meet the definition of an endangered species or threatened species under the Act.</P>
                <P>If we find that a petition presents such information, our subsequent status review will evaluate all identified threats by considering the individual-, population-, and species-level effects and the expected response by the species. We will evaluate individual threats and their expected effects on the species, then analyze the cumulative effect of the threats on the species as a whole. We also consider the cumulative effect of the threats in light of those actions and conditions that are expected to have positive effects on the species—such as any existing regulatory mechanisms or conservation efforts that may ameliorate threats. It is only after conducting this cumulative analysis of threats and the actions that may ameliorate them, and the expected effect on the species now and in the foreseeable future, that we can determine whether the species meets the definition of an endangered species or threatened species under the Act.</P>
                <P>If we find that a petition presents substantial scientific or commercial information indicating that the petitioned action may be warranted, the Act requires that we promptly commence a review of the status of the species, and we will subsequently complete a status review in accordance with our prioritization methodology for 12-month findings (81 FR 49248; July 27, 2016).</P>
                <P>
                    We note that designating critical habitat is not a petitionable action under the Act. Petitions to designate critical habitat (for species without existing critical habitat) are reviewed under the Administrative Procedure Act (5 U.S.C. 551 
                    <E T="03">et seq.</E>
                    ) and are not addressed in this finding (see 50 CFR 424.14(j)). To the maximum extent prudent and determinable, any proposed critical habitat will be addressed concurrently with a proposed rule to list a species, if applicable.
                </P>
                <HD SOURCE="HD1">Summary of Petition Finding</HD>
                <HD SOURCE="HD2">Species and Range</HD>
                <P>
                    Kings River pyrg (
                    <E T="03">Pyrgulopsis imperialis</E>
                    ); Humboldt County, Nevada.
                </P>
                <HD SOURCE="HD2">Evaluation of Information Summary</HD>
                <P>On October 31, 2023, we received a petition from the Western Watersheds Project, requesting that the Kings River pyrg, an endemic springsnail found in Humboldt County, Nevada, be listed as an endangered species or a threatened species and critical habitat be designated for this species under the Act. The petition clearly identified itself as such and included the requisite identification information for the petitioner, required at 50 CFR 424.14(c). This finding addresses the petition.</P>
                <HD SOURCE="HD2">Finding</HD>
                <P>We reviewed the petition, sources cited in the petition, and other readily available information (within the constraints of the Act and 50 CFR 424.14(h)(1)). We considered the credible information that the petition provided regarding effects of the threats that fall within factors under the Act's section 4(a)(1) as potentially ameliorated or exacerbated by any existing regulatory mechanisms or conservation efforts. Based on our review of the petition and readily available information regarding spring modification (Factor A), we find that the petition presents substantial scientific or commercial information indicating that listing the Kings River pyrg may be warranted. The petition presents credible information that all 13 known springs occupied by the Kings River pyrg exhibited signs of habitat disturbance during 2018 surveys and that the flows of 4 occupied springs have already been modified.</P>
                <P>The petition discusses several additional threats, which could ultimately result in spring modification and impacts to Kings River pyrg habitat. These threats include livestock grazing, roads, drought, climate change, and the Thacker Pass Lithium Mine. The current State of Nevada Division of Environmental Protection (NDEP) Water Pollution Control permit for the Thacker Pass Lithium Mine does not authorize mining below the groundwater table (NDEP 2022), which as written, may significantly reduce the potential for spring modification from this project. The petitioners also presented information suggesting that nonnative aquatic species, small population size and limited distribution, and the species' lack of mobility may be threats to the Kings River pyrg. We will fully evaluate all potential threats to the species during our 12-month status review, pursuant to the Act's requirement to review the best scientific and commercial information available when making that finding.</P>
                <PRTPAGE P="8631"/>
                <P>
                    The basis for our finding on this petition and other information regarding our review of the petition can be found as an appendix at 
                    <E T="03">https://www.regulations.gov</E>
                     under Docket No. FWS-R8-ES-2023-0261 under the Supporting Documents section.
                </P>
                <HD SOURCE="HD1">Conclusion</HD>
                <P>On the basis of our evaluation of the information presented in the petition under section 4(b)(3)(A) of the Act, we have determined that the petition summarized above for the Kings River pyrg presents substantial scientific or commercial information indicating that the petitioned action may be warranted. We are, therefore, initiating a status review of the species to determine whether the action is warranted under the Act. At the conclusion of the status review, we will issue a finding, in accordance with section 4(b)(3)(B) of the Act, as to whether the petitioned action is not warranted, warranted, or warranted but precluded by pending proposals to determine whether any species is an endangered species or a threatened species.</P>
                <HD SOURCE="HD1">Authors</HD>
                <P>The primary authors of this document are staff members of the Pacific Southwest Region, Ecological Services Program, U.S. Fish and Wildlife Service.</P>
                <HD SOURCE="HD1">Authority</HD>
                <P>
                    The authority for this action is the Endangered Species Act of 1973, as amended (16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Martha Williams,</NAME>
                    <TITLE>Director, U.S. Fish and Wildlife Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02620 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4333-15-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Fish and Wildlife Service</SUBAGY>
                <CFR>50 CFR Part 20</CFR>
                <DEPDOC>[Docket No. FWS-HQ-MB-2023-0113; FF09M32000-234-FXMB1231099BPP0]</DEPDOC>
                <RIN>RIN 1018-BG63</RIN>
                <SUBJECT>Migratory Bird Hunting; Proposed 2024-25 Migratory Game Bird Hunting Regulations (Preliminary)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Fish and Wildlife Service (Service or we) proposes to establish hunting regulations for certain migratory game birds for the 2024-25 hunting season. Through an annual rulemaking process, we prescribe outside limits (which we refer to as frameworks) within which States may select hunting seasons. This proposed rule provides the regulatory schedule, describes the proposed regulatory alternatives for the 2024-25 general duck seasons, and provides preliminary proposals that vary from the 2023-24 hunting season regulations. Migratory bird hunting seasons provide opportunities for recreation and sustenance; aid Federal, State, and Tribal governments in the management of migratory game birds; and permit harvests at levels compatible with migratory game bird population status and habitat conditions.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments:</E>
                         You may comment on the general duck season regulatory alternatives and other preliminary proposals for the 2024-25 season until March 11, 2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Comments:</E>
                         You may submit comments on the proposals by one of the following methods:
                    </P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                          
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the instructions for submitting comments on Docket No. FWS-HQ-MB-2023-0113.
                    </P>
                    <P>
                        • 
                        <E T="03">U.S. mail:</E>
                         Public Comments Processing, Attn: FWS-HQ-MB-2023-0113; U.S. Fish and Wildlife Service; MS: PRB/3W; 5275 Leesburg Pike; Falls Church, VA 22041-3803.
                    </P>
                    <P>
                        We will not accept emailed or faxed comments. We will post all comments on 
                        <E T="03">https://www.regulations.gov.</E>
                         This generally means that your entire submission—including any personal identifying information—will be posted on the website. See 
                        <E T="03">Public Comments,</E>
                         below, for more information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jerome Ford, U.S. Fish and Wildlife Service, Department of the Interior, (703) 358-2606; 
                        <E T="03">jerome_ford@fws.gov.</E>
                         For a summary of the rule, please see the “rule summary document” in docket FWS-HQ-MB-2023-0113 on 
                        <E T="03">https://www.regulations.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Process for Establishing Annual Migratory Game Bird Hunting Regulations</HD>
                <HD SOURCE="HD2">Background</HD>
                <P>Migratory game birds are those bird species so designated in conventions between the United States and several foreign nations for the protection and management of these birds. Under the Migratory Bird Treaty Act (MBTA; 16 U.S.C. 703-712), the Secretary of the Interior is authorized to determine when “hunting, taking, capture, killing, possession, sale, purchase, shipment, transportation, carriage, or export of any such bird, or any part, nest, or egg” of migratory game birds can take place, and to adopt regulations for this purpose (16 U.S.C. 704(a)). These regulations are written after giving due regard to “the zones of temperature and to the distribution, abundance, economic value, breeding habits, and times and lines of migratory flight of such birds” (16 U.S.C. 704(a)) and are updated annually. This responsibility has been delegated to the Service as the lead Federal agency for managing and conserving migratory birds in the United States. However, migratory bird management is a cooperative effort of Federal, State, and Tribal governments.</P>
                <P>The Service annually develops migratory game bird hunting regulations by establishing the frameworks, or outside limits, for season dates, season lengths, shooting hours, bag and possession limits, and areas where migratory game bird hunting may occur. These frameworks are necessary to allow harvest at levels compatible with migratory game bird population status and habitat conditions. After the frameworks are established, States may select migratory game bird hunting seasons within the frameworks. States may always be more conservative in their selections than the frameworks, but never more liberal. The annual process of developing migratory game bird hunting regulations concludes when we establish the State season selections as Federal regulations under title 50 of the Code of Federal Regulations, part 20, subpart K.</P>
                <P>Acknowledging regional differences in hunting conditions, the Service has administratively divided the United States into four Flyways for the primary purpose of managing migratory game birds. Each Flyway (Atlantic, Mississippi, Central, and Pacific) has a Flyway Council, a formal organization generally composed of one member from each State within the Flyway, as well as Provinces in Canada that share migratory bird populations with the Flyway. The Flyway Councils, established through the Association of Fish and Wildlife Agencies, also assist in researching and providing migratory game bird management information for Federal, State, Tribal, and Provincial governments, as well as private conservation entities and the general public.</P>
                <HD SOURCE="HD2">Overview of the Rulemaking Process</HD>
                <P>
                    The process for adopting migratory game bird hunting regulations, which are set forth at 50 CFR part 20, is constrained by three primary factors. 
                    <PRTPAGE P="8632"/>
                    Legal and administrative considerations dictate how long the rulemaking process will last. Most importantly, however, the biological cycle of migratory game birds controls the timing of data-gathering activities and thus the dates on which these results are available for consideration and deliberation.
                </P>
                <P>For the regulatory cycle, Service biologists gather, analyze, and interpret biological survey data and provide this information to all those involved in the process through a series of published status reports and presentations to Flyway Councils and other interested parties. Because the Service is required to take abundance of migratory game birds and other factors into consideration, the Service undertakes a number of surveys throughout the year in conjunction with Service Regional Offices, the Canadian Wildlife Service, and State and Provincial wildlife-management agencies. To determine the appropriate frameworks for each species, we consider factors such as population size and trend, geographical distribution, annual breeding effort, condition of breeding and wintering habitat, number of hunters, and anticipated harvest.</P>
                <HD SOURCE="HD2">Service Migratory Bird Regulations Committee Meetings</HD>
                <P>
                    The Service Migratory Bird Regulations Committee (SRC) conducted an open meeting on May 31, 2023, to discuss preliminary issues for the 2024-25 regulations and will conduct another meeting in fall 2023 to review information on the current status of migratory game birds and develop recommendations for the 2024-25 hunting regulations for these species. In accordance with 50 CFR 20.153, these meetings are open to public observation, and observers may submit written comments to the Service on the matters discussed. These meetings are announced in the 
                    <E T="04">Federal Register</E>
                     or online on the Service's Migratory Bird Program website at least 2 weeks before the meeting date.
                </P>
                <HD SOURCE="HD1">Rulemaking Process for the 2024-25 Season</HD>
                <P>This document is the first in a series of proposed and final rulemaking documents for migratory game bird hunting regulations. This document announces our intent to establish open hunting seasons for certain designated groups or species of migratory game birds for 2024-25 in the contiguous United States, Alaska, Hawaii, Puerto Rico, and the Virgin Islands, under §§ 20.101 through 20.107, 20.109, and 20.110 of 50 CFR part 20, subpart K. For the 2024-25 migratory game bird hunting season, we will propose regulations for certain designated members of the avian families Anatidae (ducks, geese, and swans); Columbidae (doves and pigeons); Gruidae (cranes); Rallidae (rails, coots, and gallinules); and Scolopacidae (woodcock and snipe).</P>
                <P>
                    The proposed regulatory alternatives for the 2024-25 duck hunting seasons are contained at the end of this document. We will publish additional proposals for public comment in the 
                    <E T="04">Federal Register</E>
                     as population, habitat, harvest, and other information become available. We annually publish definitions of flyways and management units and a description of the data used in and the factors affecting the regulatory process. This information will be included in proposed and final rules later in the regulations-development process (see 88 FR 6054, January 30, 2023, for the latest definitions and descriptions). Major steps in the 2024-25 regulatory cycle relating to open public meetings and 
                    <E T="04">Federal Register</E>
                     notifications are illustrated in the diagram at the end of this proposed rule. All publication dates of 
                    <E T="04">Federal Register</E>
                     documents are target dates. Our goal is to publish final regulatory alternatives for duck seasons and proposed season frameworks in winter 2023 and final season frameworks in spring 2024.
                </P>
                <HD SOURCE="HD2">Subject Matter Organization</HD>
                <P>Sections of this and subsequent documents outlining hunting frameworks and guidelines are organized under numbered headings. These headings are:</P>
                <EXTRACT>
                    <FP SOURCE="FP-2">1. Ducks</FP>
                    <FP SOURCE="FP1-2">A. General Harvest Strategy</FP>
                    <FP SOURCE="FP1-2">B. Regulatory Alternatives</FP>
                    <FP SOURCE="FP1-2">C. Zones and Split Seasons</FP>
                    <FP SOURCE="FP1-2">D. Special Seasons/Species Management</FP>
                    <FP SOURCE="FP1-2">i. Early Teal Seasons</FP>
                    <FP SOURCE="FP1-2">ii. Early Teal/Wood Duck Seasons</FP>
                    <FP SOURCE="FP1-2">iii. Black Ducks</FP>
                    <FP SOURCE="FP1-2">iv. Canvasbacks</FP>
                    <FP SOURCE="FP1-2">v. Pintails</FP>
                    <FP SOURCE="FP1-2">vi. Scaup</FP>
                    <FP SOURCE="FP1-2">vii. Mottled Ducks</FP>
                    <FP SOURCE="FP1-2">viii. Wood Ducks</FP>
                    <FP SOURCE="FP1-2">ix. Eastern Mallards</FP>
                    <FP SOURCE="FP1-2">x. Youth and Veterans-Active-Military-Personnel Hunting Days</FP>
                    <FP SOURCE="FP1-2">xi. Mallard Management Units</FP>
                    <FP SOURCE="FP1-2">xii. Other</FP>
                    <FP SOURCE="FP-2">2. Sea Ducks</FP>
                    <FP SOURCE="FP-2">3. Mergansers</FP>
                    <FP SOURCE="FP-2">4. Canada Geese</FP>
                    <FP SOURCE="FP1-2">A. Special Early Seasons</FP>
                    <FP SOURCE="FP1-2">B. Regular Seasons</FP>
                    <FP SOURCE="FP1-2">C. Special Late Seasons</FP>
                    <FP SOURCE="FP-2">5. White-fronted Geese</FP>
                    <FP SOURCE="FP-2">6. Brant</FP>
                    <FP SOURCE="FP-2">7. Snow and Ross's (Light) Geese</FP>
                    <FP SOURCE="FP-2">8. Swans</FP>
                    <FP SOURCE="FP-2">9. Sandhill Cranes</FP>
                    <FP SOURCE="FP-2">10. Coots</FP>
                    <FP SOURCE="FP-2">11. Gallinules</FP>
                    <FP SOURCE="FP-2">12. Rails</FP>
                    <FP SOURCE="FP-2">13. Snipe</FP>
                    <FP SOURCE="FP-2">14. Woodcock</FP>
                    <FP SOURCE="FP-2">15. Band-tailed Pigeons</FP>
                    <FP SOURCE="FP-2">16. Doves</FP>
                    <FP SOURCE="FP-2">17. Alaska</FP>
                    <FP SOURCE="FP-2">18. Hawaii</FP>
                    <FP SOURCE="FP-2">19. Puerto Rico</FP>
                    <FP SOURCE="FP-2">20. Virgin Islands</FP>
                    <FP SOURCE="FP-2">21. Falconry</FP>
                    <FP SOURCE="FP-2">22. Other</FP>
                </EXTRACT>
                <P>This and subsequent documents will refer only to numbered items requiring attention at the time of publication. Because this and other documents will omit those items not requiring attention, the remaining numbered items may be discontinuous and the list may appear incomplete.</P>
                <HD SOURCE="HD2">Tribal Regulations</HD>
                <P>
                    As part of our effort to improve the annual rulemaking process, we developed regulations pertaining to Tribes differently than we have in the past. Since the 1985-86 hunting season, we have employed guidelines described in the June 4, 1985, 
                    <E T="04">Federal Register</E>
                     (50 FR 23459) to establish special migratory game bird hunting regulations on Federal Indian reservations (including off-reservation trust lands) and ceded lands. We developed these guidelines in response to Tribal requests for our recognition of their reserved hunting rights, and for some Tribes, recognition of their authority to regulate hunting by both Tribal and nontribal members throughout their reservations. On September 1, 2023, we published a final rule for Migratory Game Bird Hunting Regulations on Certain Federal Indian Reservations and Ceded Lands (88 FR 60375). For inquiries on Tribal guidelines, Tribes should contact the address indicated under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <HD SOURCE="HD1">Public Comments</HD>
                <P>The Department of the Interior's policy is, whenever practicable, to afford the public an opportunity to participate in the rulemaking process. Accordingly, we invite interested persons to submit written comments, suggestions, or recommendations regarding this proposed rule. We seek information and comments on the proposed regulatory alternatives for the 2024-25 general duck hunting seasons, other recommended changes or specific preliminary proposals that vary from the 2023-24 regulations, and issues requiring early discussion, action, or the attention of the States.</P>
                <P>
                    The Service believes that a 30-day comment period is warranted for this 
                    <PRTPAGE P="8633"/>
                    proposed rule as subsequent 
                    <E T="04">Federal Register</E>
                     documents will allow the public to submit comments on the overall hunting frameworks (see 
                    <E T="03">Schedule of Biological Information Availability, Regulations Meetings, and</E>
                      
                    <E T="04">Federal Register</E>
                    <E T="03"> Publications for the 2024-25 Hunting Season</E>
                     at the end of this proposed rule for further information). For each subsequent proposed rule associated with this rulemaking action, we will establish a specific comment period. Before promulgation of final migratory game bird hunting regulations, we will take into consideration all comments we receive. We will summarize the comments received and publish responses to all proposals and written comments when we develop final frameworks for the 2024-25 season. Such comments, and any additional information we receive, may lead to final regulations that differ from the proposed rules.
                </P>
                <P>
                    You may submit your comments and materials concerning this proposed rule by one of the methods listed in 
                    <E T="02">ADDRESSES</E>
                    . We will not accept comments sent by email or fax or to an address not listed in 
                    <E T="02">ADDRESSES</E>
                    . Finally, we will not consider mailed comments that are not postmarked by the date specified in 
                    <E T="02">DATES</E>
                    . We will post all comments in their entirety—including your personal identifying information—on 
                    <E T="03">https://www.regulations.gov.</E>
                     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. Comments and materials we receive, as well as supporting documentation we used in preparing this proposed rule, will be available for public inspection on 
                    <E T="03">https://www.regulations.gov.</E>
                </P>
                <HD SOURCE="HD1">Required Determinations</HD>
                <HD SOURCE="HD2">National Environmental Policy Act (NEPA) Consideration</HD>
                <P>
                    The programmatic document, “Second Final Supplemental Environmental Impact Statement: Issuance of Annual Regulations Permitting the Sport Hunting of Migratory Birds (EIS 20130139),” filed with the Environmental Protection Agency (EPA) on May 24, 2013, addresses NEPA compliance by the Service for issuance of the annual framework regulations for hunting of migratory game bird species. We published a notice of availability in the 
                    <E T="04">Federal Register</E>
                     on May 31, 2013 (78 FR 32686), and our Record of Decision on July 26, 2013 (78 FR 45376). We also address NEPA compliance for waterfowl hunting frameworks through the annual preparation of separate environmental assessments, the most recent being “Duck Hunting Regulations for 2023-24,” with its corresponding January 2023 finding of no significant impact. In addition, an August 1985 environmental assessment entitled “Guidelines for Migratory Bird Hunting Regulations on Federal Indian Reservations and Ceded Lands” is available from the person listed above under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <HD SOURCE="HD2">Endangered Species Act Consideration</HD>
                <P>Before issuance of the 2024-25 migratory game bird hunting regulations, we will comply with provisions of the Endangered Species Act of 1973, as amended (ESA; 16 U.S.C. 1531-1543), to ensure that hunting is not likely to jeopardize the continued existence of any species designated as endangered or threatened or adversely modify or destroy its critical habitat and is consistent with conservation programs for those species. Consultations under section 7 of the ESA may cause us to change proposals in future supplemental proposed rulemaking documents.</P>
                <HD SOURCE="HD2">Regulatory Planning and Review—Executive Orders 12866, 13563, and 14094</HD>
                <P>Executive Order 14094 reaffirms the principles of E.O. 12866 and E.O. 13563. Regulatory analysis should facilitate agency efforts to develop regulations that serve the public interest, advance statutory objectives, and are consistent with E.O. 12866, E.O. 13563, and the Presidential Memorandum of January 20, 2021 (Modernizing Regulatory Review). Regulatory analysis, as practicable and appropriate, shall recognize distributive impacts and equity, to the extent permitted by law. We have developed this proposed rule in a manner consistent with these requirements.</P>
                <P>E.O. 12866, as reaffirmed by E.O. 13563 and amended by E.O. 14094, provides that the Office of Information and Regulatory Affairs (OIRA) in the Office of Management and Budget (OMB) will review all significant rules. This action is a “significant regulatory action,” as defined under section 3(f)(1) of E.O. 12866 (58 FR 51735, October 4, 1993), as amended by E.O. 14094 (88 FR 21879, April 11, 2023).</P>
                <P>
                    An economic analysis was prepared for the 2024-25 migratory bird hunting season. This analysis was based on data from the 2011 and the 2016 National Survey of Fishing, Hunting, and Wildlife-Associated Recreation (National Survey), the most recent years for which data are available. See discussion under Required Determinations, 
                    <E T="03">Regulatory Flexibility Act,</E>
                     below. This analysis estimated consumer surplus for four alternatives for duck hunting regulations. As defined by OMB in Circular A-4, consumers' surplus is the difference between what a consumer pays for a unit of a good or service and the maximum amount the consumer would be willing to pay for that unit. The duck hunting regulatory alternatives are (1) not opening a hunting season, (2) issuing restrictive regulations that allow fewer days than the 2023-24 season, (3) issuing moderate regulations that allow more days than in Alternative 2 but fewer days than the 2023-24 season, and (4) issuing liberal regulations that allow days similar to the 2023-24 season. The estimated consumer surplus associated with liberal regulations issued for the 2023-24 season across all flyways was $356 million. We also chose Alternative 4 (liberal regulations) for the 2009-10 through 2022-23 seasons. The 2024-25 analysis is part of the record for this rulemaking action and is available at 
                    <E T="03">https://www.regulations.gov</E>
                     at Docket No. FWS-HQ-MB-2023-0113.
                </P>
                <HD SOURCE="HD2">Regulatory Flexibility Act</HD>
                <P>
                    The annual migratory bird hunting regulations have a significant economic impact on substantial numbers of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ). An initial regulatory flexibility analysis was prepared to analyze the economic impacts of the annual hunting regulations on small business entities. This analysis is updated annually. The primary source of information about hunter expenditures for migratory game bird hunting is the National Survey, which is generally conducted at 5-year intervals. The 2024-25 migratory bird hunting season analysis is based on the 2011 and 2016 National Surveys and the U.S. Department of Commerce's County Business Patterns, from which it is estimated that migratory bird hunters would spend approximately $2.5 billion (2022$) at small businesses during the 2024-25 migratory bird hunting season. Copies of the analysis are available upon request from the person listed above under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     or from 
                    <E T="03">
                        https://
                        <PRTPAGE P="8634"/>
                        www.regulations.gov
                    </E>
                     at Docket No. FWS-HQ-MB-2023-0113.
                </P>
                <HD SOURCE="HD2">Congressional Review Act</HD>
                <P>
                    Pursuant to subtitle E of the Small Business Regulatory Enforcement Fairness Act (also known as the Congressional Review Act or CRA), 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     OIRA designated this action as a major rule, as defined by 5 U.S.C. 804(2), because it is likely to result in an annual effect on the economy of $100 million or more. However, because this proposed rule would establish a regulatory program for activity related to hunting and because hunting seasons are time sensitive, we plan to establish the effective dates of the final rules using the exemption in the CRA at 5 U.S.C. 808(1).
                </P>
                <HD SOURCE="HD2">Clarity of the Rule</HD>
                <P>We are required by E.O. 12866 and 12988 and by the Presidential Memorandum of June 1, 1998, to write all rules in plain language. This means that each rule we publish must:</P>
                <P>(a) Be logically organized;</P>
                <P>(b) Use the active voice to address readers directly;</P>
                <P>(c) Use clear language rather than jargon;</P>
                <P>(d) Be divided into short sections and sentences; and</P>
                <P>(e) Use lists and tables wherever possible.</P>
                <P>
                    If you feel that we have not met these requirements, send us comments by one of the methods listed in 
                    <E T="02">ADDRESSES</E>
                    . To better help us revise the rule, your comments should be as specific as possible. For example, you should tell us the numbers of the sections or paragraphs that are unclearly written, which sections or sentences are too long, the sections where you feel lists or tables would be useful, etc.
                </P>
                <HD SOURCE="HD2">Paperwork Reduction Act</HD>
                <P>
                    This rule does not contain any new collection of information that requires approval by the Office of Management and Budget (OMB) under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ). OMB has previously approved the information collection requirements associated with migratory bird surveys and the procedures for establishing annual migratory bird hunting seasons under the following OMB control numbers:
                </P>
                <P>• 1018-0019, “North American Woodcock Singing Ground Survey” (expires 02/29/2024).</P>
                <P>• 1018-0023, “Migratory Bird Surveys, 50 CFR 20.20” (expires 05/31/2026). Includes Migratory Bird Harvest Information Program, Migratory Bird Hunter Surveys, Sandhill Crane Survey, and Parts Collection Survey.</P>
                <P>• 1018-0171, “Establishment of Annual Migratory Bird Hunting Seasons, 50 CFR part 20” (expires 10/31/2024).</P>
                <P>
                    You may view the information collection request(s) at 
                    <E T="03">http://www.reginfo.gov/public/do/PRAMain.</E>
                     An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.
                </P>
                <HD SOURCE="HD2">Unfunded Mandates Reform Act</HD>
                <P>
                    We have determined and certify, in compliance with the requirements of the Unfunded Mandates Reform Act, 2 U.S.C. 1501 
                    <E T="03">et seq.,</E>
                     that this proposed rulemaking does not include any Federal mandate that may result in the expenditure by State, local, and Tribal governments, in the aggregate, or by the private sector, of $100 million or more (adjusted for inflation) in any 1 year and does not significantly or uniquely affect small governments.
                </P>
                <HD SOURCE="HD2">Civil Justice Reform—Executive Order 12988</HD>
                <P>The Department, in promulgating this proposed rule, has determined that this rule will not unduly burden the judicial system and that it meets the requirements of sections 3(a) and 3(b)(2) of E.O. 12988.</P>
                <HD SOURCE="HD2">Takings Implication Assessment—Executive Order 12630</HD>
                <P>In accordance with E.O. 12630, this proposed rule, authorized by the MBTA, does not have significant takings implications and does not affect any constitutionally protected property rights. This proposed rule would not result in the physical occupancy of property, the physical invasion of property, or the regulatory taking of any property. In fact, this proposed rule would allow hunters to exercise otherwise unavailable privileges and, therefore, would reduce restrictions on the use of private and public property.</P>
                <HD SOURCE="HD2">Energy Effects—Executive Order 13211</HD>
                <P>E.O. 13211 requires agencies to prepare statements of energy effects when undertaking certain actions. While this proposed rule is a significant regulatory action under E.O. 12866, it is not likely to have a significant adverse effect on the supply, distribution, or use of energy and has not been designated by OIRA as a significant energy action. Therefore, no statement of energy effects is required.</P>
                <HD SOURCE="HD2">Government-to-Government Relationship With Tribes</HD>
                <P>In accordance with the President's memorandum of April 29, 1994, “Government-to-Government Relations with Native American Tribal Governments” (59 FR 22951), E.O. 13175, and 512 DM 2, we have evaluated possible effects on federally recognized Indian Tribes and have determined that there are de minimis effects on Indian Tribes. Through this process to establish annual hunting regulations, we regularly coordinate with Tribes that are affected by this rulemaking action. This proposed rule is general in nature and does not directly affect any specific Tribal lands, treaty rights, or Tribal trust resources. In addition, this proposed rule would not interfere with the ability of Tribes to manage themselves or their funds or to regulate migratory bird activities on Tribal lands. Therefore, we preliminarily conclude that this proposed rule does not have “Tribal implications” under section 1(a) of E.O. 13175. Thus, formal government-to-government consultation is not required by E.O. 13175 and related policies of the Department of the Interior. We will continue to collaborate with Tribes on concerns related to migratory bird hunting regulations.</P>
                <P>
                    We routinely provide 
                    <E T="04">Federal Register</E>
                     publications and biological status reports pertaining to migratory bird management and regulations online for all Tribes, State Directors, and other interested parties. Upon being notified of any concern regarding proposed and final regulations, we have initiated consultation, and we will continue to consult with Tribes when necessary.
                </P>
                <HD SOURCE="HD2">Federalism Effects—Executive Order 13132</HD>
                <P>
                    Due to the migratory nature of certain species of birds, the Federal Government has been given responsibility over these species by the MBTA. We annually prescribe frameworks from which the States make selections regarding the hunting of migratory birds, and we employ guidelines to establish special regulations on Federal Indian reservations and ceded lands. This process preserves the ability of the States and Tribes to determine which seasons meet their individual needs. Any State or Tribe may be more restrictive in its regulations than the Federal frameworks at any time. The frameworks are developed in a cooperative process with the States and the Flyway Councils. This process allows States to participate in the 
                    <PRTPAGE P="8635"/>
                    development of frameworks from which they will make selections, thereby having an influence on their own regulations. These rules do not have substantial direct effects on the States, on the relationship between the national government and the States, or on the distribution of power and responsibilities among the various levels of government. Therefore, in accordance with E.O. 13132, these regulations do not have federalism implications and do not warrant the preparation of a federalism summary impact statement.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 50 CFR Part 20</HD>
                    <P>Exports, Hunting, Imports, Reporting and recordkeeping requirements, Transportation, Wildlife.</P>
                </LSTSUB>
                <HD SOURCE="HD1">Authority</HD>
                <P>The rules that eventually will be promulgated for the 2024-25 hunting season are authorized under 16 U.S.C. 703-711, 712, and 742 a-j.</P>
                <SIG>
                    <NAME>Shannon A. Estenoz,</NAME>
                    <TITLE>Assistant Secretary for Fish and Wildlife and Parks.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Proposed 2024-25 Migratory Game Bird Hunting Regulations (Preliminary)</HD>
                <P>Pending current information on populations, harvest, and habitat conditions, and receipt of recommendations from the four Flyway Councils, we may defer specific regulatory proposals. Issues requiring early discussion, action, or the attention of the States or Tribes are described below.</P>
                <HD SOURCE="HD3">1. Ducks</HD>
                <P>As mentioned earlier in this document, the categories used to discuss issues related to duck harvest management are: (A) General Harvest Strategy, (B) Regulatory Alternatives, (C) Zones and Split Seasons, and (D) Special Seasons/Species Management. Only those categories containing substantial recommendations (A, B, and D) are discussed below.</P>
                <HD SOURCE="HD2">A. General Harvest Strategy</HD>
                <P>We will continue to use adaptive harvest management (AHM) to help determine appropriate duck-hunting regulations for the 2024-25 season. AHM is a tool that permits sound resource decisions in the face of uncertain regulatory impacts and provides a mechanism for reducing that uncertainty over time. We use an AHM protocol (decision framework) to evaluate four regulatory alternatives, each with a different expected harvest level, and choose the optimal regulation for duck hunting based on the status and demographics of mallards for the Mississippi, Central, and Pacific Flyways, and based on the status and demographics of a suite of four species (eastern waterfowl) in the Atlantic Flyway. We have specific AHM protocols that guide appropriate bag limits and season lengths for species of special concern, including black ducks, scaup, pintails, and mallards in the Atlantic Flyway (eastern mallards), within the general duck season. These protocols use the same outside season dates and lengths as those regulatory alternatives for the 2024-25 general duck seasons.</P>
                <P>
                    For the 2024-25 hunting season, we will continue to use independent optimizations to determine the appropriate regulatory alternative for mallard stocks in the Mississippi, Central, and Pacific Flyways and for eastern waterfowl in the Atlantic Flyway. This means that we will develop regulations for mid-continent mallards, western mallards, and eastern waterfowl independently based on the breeding stock that contributes primarily to each Flyway. We detailed implementation of AHM protocols for mid-continent and western mallards in the July 24, 2008, 
                    <E T="04">Federal Register</E>
                     (73 FR 43290), and for eastern waterfowl in the September 21, 2018, 
                    <E T="04">Federal Register</E>
                     (83 FR 47868).
                </P>
                <HD SOURCE="HD2">B. Regulatory Alternatives</HD>
                <P>The basic structure of the current regulatory alternatives for AHM was adopted in 1997 (beginning with the 1997-98 general duck hunting season; 62 FR 31298, June 6, 1997). Beginning with the 2002-03 season, based upon recommendations from the Flyway Councils, we extended framework dates in the “moderate” and “liberal” regulatory alternatives by changing the opening date from the Saturday nearest October 1 to the Saturday nearest September 24, and by changing the closing date from the Sunday nearest January 20 to the last Sunday in January (67 FR 47224, July 17, 2002). These extended dates were made available with no associated penalty in season length or bag limits. Beginning with the 2019-20 season, we adopted a closing duck framework date of January 31 for the “moderate” and “liberal” alternatives in the Atlantic Flyway as part of the Atlantic Flyway's eastern waterfowl AHM protocol (83 FR 47868, September 21, 2018). We subsequently proposed to extend the framework closing date to January 31 across all four Flyways for the 2019-20 season (84 FR 16152, April 17, 2019).</P>
                <P>The John D. Dingell, Jr. Conservation, Management, and Recreation Act of 2019 (Pub. L. 116-9, Dingell Act) amended the MBTA to establish that the closing framework date for duck seasons will be January 31, unless a flyway chooses an earlier closing date. Thus, as directed by the Dingell Act, we adjusted the framework closing date under each regulatory alternative for all four Flyways to January 31 beginning with the 2019-20 season (84 FR 42996, August 19, 2019). Beginning with the 2021-22 season, we agreed to move the opening framework date to 1 week earlier in the restrictive regulatory alternative for the Mississippi and Central Flyways based on their recommendations (85 FR 51854, August 21, 2020).</P>
                <P>
                    For the 2024-25 general duck season, we propose to use the same regulatory alternatives that are in effect for the 2023-24 season (see table at the end of this proposed rule for specifics of the regulatory alternatives). Alternatives are specified for each Flyway and are designated as “RES” for the restrictive, “MOD” for the moderate, and “LIB” for the liberal alternative. We plan to finalize AHM regulatory alternatives for the 2024-25 season in a proposed rule, which we plan to publish by winter 2023 (see 
                    <E T="03">Schedule of Biological Information Availability, Regulations Meetings, and Federal Register Publications for the 2024-25 Hunting Season</E>
                     at the end of this proposed rule for further information).
                </P>
                <HD SOURCE="HD2">D. Special Seasons/Species Management</HD>
                <HD SOURCE="HD3">xii. Other</HD>
                <P>
                    Although not part of any current harvest management strategy, we propose to allow South Dakota and Nebraska to continue to conduct a pilot study during the 2024-25 duck season of a two-tier regulatory system as described in the March 19, 2020, proposed rule (85 FR 15870). This would be the last year of a planned 4-year pilot study. The intent of the two-tier regulation study is to evaluate whether regulations that relax the requirement for hunters to identify duck species can improve waterfowl hunter recruitment and retention.
                    <SU>1</SU>
                    <FTREF/>
                     Declines in 
                    <PRTPAGE P="8636"/>
                    waterfowl hunter numbers have been of concern to the Service and the Flyway Councils, prompting the development of recruitment, retention, and reactivation efforts in the conservation community. The study would allow a person to obtain one of two license types during the duck season. The first license type would allow a daily bag limit as specified in the current duck regulations (six ducks), along with attendant species and sex restrictions. The second license type would allow a daily bag limit of only three ducks, but they could be of any species or sex. Memoranda of agreement between the Service and the two States specify the purpose of the study and the roles and responsibilities of each party while conducting the pilot study. A final report for the pilot study will be due to the Service after the 2024-25 hunting season.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The Service's primary goal is to ensure that waterfowl sport harvest management conforms to the MBTA and ensures the long-term conservation of bird populations. The various harvest strategies reflect this goal by ensuring that harvest does not exceed maximum sustainable yield (MSY). Secondarily to the MBTA, the Service has adopted policies to promote wildlife-based recreation, including migratory bird harvest. To the extent that management actions designed to promote hunter recruitment and retention do not result in harvest greater than the biological capacity of a population (
                        <E T="03">i.e.,</E>
                         does not exceed MSY), the Service deems these 
                        <PRTPAGE/>
                        actions to be in accordance with the MBTA. Management actions that result in harvest equal to or less than MSY will result in stable or increasing populations and provide consumptive and nonconsumptive uses indefinitely.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="640">
                    <PRTPAGE P="8637"/>
                    <GID>EP08FE24.035</GID>
                </GPH>
                <GPH SPAN="3" DEEP="640">
                    <PRTPAGE P="8638"/>
                    <GID>EP08FE24.036</GID>
                </GPH>
                <PRTPAGE P="8639"/>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02517 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4333-15-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 622</CFR>
                <DEPDOC>[Docket No. 240202-0034]</DEPDOC>
                <RIN>RIN 0648-BM80</RIN>
                <SUBJECT>Fisheries of the Caribbean, Gulf of Mexico, and South Atlantic; Atlantic Coastal Migratory Pelagic Fishery; Atlantic Dolphin and Wahoo Fishery; and South Atlantic Snapper-Grouper Fishery; Control Date</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Advanced notice of proposed rulemaking; request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This advance notice of proposed rulemaking seeks comment on the benefits or disadvantages of the South Atlantic Fishery Management Council (Council) potentially setting future restrictions, resulting in subsequent rulemakings from NMFS, in the Atlantic the coastal migratory pelagics fishery and the dolphin and wahoo fishery, and the snapper-grouper fishery in the South Atlantic. The Council recently set a control date of December 8, 2023. That control date, and an existing control date of June 15, 2016, may both be used to create restrictions limiting participation in the exclusive economic zone for the Federal charter vessel/headboat (for-hire) components of the recreational sectors of the coastal migratory pelagics fishery in the Atlantic, dolphin and wahoo fishery in the Atlantic, and snapper-grouper fishery in the South Atlantic. The Council is considering a future action that may affect or limit the number of participants in the fishery, and stresses that participants should locate and preserve all relevant, fishing-related documents. If such an action is developed, approved, and implemented through a Council decision and a subsequent rulemaking by NMFS, future access to the fishery after the control date would not be assured. NMFS is informing the public of the new control date, in part, to promote awareness of the potential changes to eligibility criteria for future access so as to discourage speculative entry into the Federal for-hire components of the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, or the South Atlantic snapper-grouper fisheries, while the Council and NMFS consider whether and how access to these for-hire components should be managed.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments must be received no later than March 11, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments identified by “NOAA-NMFS-2023-0157” by either of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Electronic Submission:</E>
                         Submit all electronic public comments via the Federal e-Rulemaking Portal. Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and type “NOAA-NMFS-2023-0157” in the Search box (
                        <E T="03">note:</E>
                         copying and pasting the FDMS Docket Number directly from this document may not yield search results). Click on the “Comment” icon, complete the required fields, and enter or attach your comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Submit written comments to Nikhil Mehta, NMFS Southeast Regional Office, 263 13th Avenue South, St. Petersburg, FL 33701.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         Comments sent by any other method, to any other address or individual, or received after the end of the comment period, may not be considered by NMFS. All comments received are a part of the public record and will generally be posted for public viewing on 
                        <E T="03">https://www.regulations.gov</E>
                         without change. All personal identifying information (
                        <E T="03">e.g.,</E>
                         name, address, 
                        <E T="03">etc.</E>
                        ), confidential business information, or otherwise sensitive information submitted voluntarily by the sender will be publicly accessible. NMFS will accept anonymous comments (enter “N/A” in the required fields if you wish to remain anonymous).
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Nikhil Mehta, telephone: 727-824-5305, or email: 
                        <E T="03">nikhil.mehta@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The coastal migratory pelagics fishery in the Atlantic is managed under the Fishery Management Plan (FMP) for Coastal Migratory Pelagic Resources (CMP FMP). The dolphin and wahoo fishery in the Atlantic is managed under the FMP for the Dolphin and Wahoo Fishery of the Atlantic (Dolphin and Wahoo FMP). The snapper-grouper fishery in the South Atlantic is managed under the FMP for the Snapper-Grouper Fishery of the South Atlantic Region (Snapper-Grouper FMP). The CMP FMP was prepared jointly by the Gulf of Mexico and South Atlantic Fishery Management Councils. The Dolphin and Wahoo and Snapper-Grouper FMPs were prepared by the Council. Under the authority of the Magnuson-Stevens Fishery Conservation and Management Act (Magnuson-Stevens Act), NMFS approved the FMPs and implements them through regulations at 50 CFR part 622.</P>
                <P>The purpose of a control date is to enable the Council to inform current and potential participants that it is considering whether to create restrictions that limit participation in a fishery. NMFS previously published a control date of June 15, 2016, for the coastal migratory pelagics, dolphin and wahoo, and snapper-grouper for-hire components of the recreational sector on September 27, 2016 (81 FR 66244). At its December 2023 meeting, the Council again discussed access options for these fisheries and requested that NMFS publish another control date of December 8, 2023, for the Federal for-hire component of the recreational sectors of the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, and South Atlantic snapper-grouper fisheries as a possible future eligibility criteria for these fisheries. The Federal charter vessel/headboat permits for these for-hire components are currently open access, available to be applied for by anyone with a valid vessel registration. The new control date of December 8, 2023, and the existing control date of June 15, 2016, could both be considered as possible options for use by the Council to determine future access to these fisheries. The purpose of these control dates is to inform current and potential participants that the Council is considering whether to propose future restrictions that limit fishery participation in the for-hire components of these fisheries. Should the Council decide to implement further restrictions on the fishery, those restrictions would be codified into the regulations through a NMFS rulemaking.</P>
                <P>
                    As a condition of the for-hire, December 8, 2023, control date, the Council specified at their December 2023 meeting that Federal permit holders that had not reported catch from the for-hire components of these fisheries to the Southeast For-Hire Integrated Electronic Reporting (SEFHIER) program in the Atlantic on, or prior to, December 5, 2023, would not be assured of future access should a management regime that limits participation in the for-hire components of these fisheries be prepared and implemented. The Atlantic SEFHIER program was implemented on January 4, 2021 (85 FR 47917, August 7, 2020). That final rule established weekly electronic reporting requirements for owners or operators of federally permitted coastal migratory pelagics, dolphin and wahoo, and snapper-
                    <PRTPAGE P="8640"/>
                    grouper charter vessels and changed the electronic reporting deadline for owners and operators of federally permitted headboats. The purpose of that final rule and the Atlantic SEFHIER program was to improve recreational fisheries management of the for-hire components in the Atlantic. NMFS notes that as of October 2023, 54 percent of vessels in the Atlantic SEFHIER program were missing required reports since the implementation of the program (
                    <E T="03">https://safmc.net/documents/fc1_a2_sefhier-program-analysis_202312-revised-pdf/</E>
                    ). The Council chose Tuesday, December 5, 2023, because Atlantic SEFHIER participants are required to report their catch weekly on Tuesdays and in order to avoid a possible influx of late reports occurring prior to December 8, 2023, by permit holders in reaction to the announcement of the control date. Late reporting by SEFHIER participants can negatively impact reliable and timely catch and effort data, decrease accuracy of reports, and increase recall bias of participants.
                </P>
                <P>In addition to selecting a control date, at their December 2023 meeting, the Council also approved a motion to initiate an amendment to the CMP FMP, the dolphin and wahoo FMP, and the snapper-grouper FMP to consider establishing limited entry for the for-hire components of the recreational sectors of Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, and South Atlantic snapper-grouper fisheries.</P>
                <P>NMFS is therefore, informing current and potential fishery participants in the Federal for-hire components of the recreational sectors for Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, and South Atlantic snapper-grouper fisheries that began participating after December 8, 2023, that they may not be ensured participation under future management of these fisheries, should the Council elect to implement, and NMFS subsequently codify, further restrictions. Additionally, Federal permit holders that have not reported catch from these fisheries to the Atlantic SEFHIER Program on, or prior to, December 5, 2023, will not be assured of future access should a management regime that limits participation in the Federal charter vessel/headboat (for-hire) component of the recreational sectors is implemented. If the Council decides to amend the FMPs to restrict participation in the Federal for-hire components of the recreational sectors of the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, or South Atlantic snapper-grouper fisheries in relation to this control date, an analysis of the specific administrative, biological, economic, and social effects will be prepared at that time. The Gulf of Mexico Fishery Management Council will also need to approve any such action taken toward the management of any species within the CMP FMP.</P>
                <P>
                    Participants, and other persons, interested in obtaining a Federal for-hire permit for the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, or South Atlantic snapper-grouper fisheries after the control date are not assured of future access to these for-hire components should management changes be implemented that would restrict participation. Such management changes would require preparation of amendments to the respective FMPs, NMFS publication of a notice of availability and proposed rule in the 
                    <E T="04">Federal Register</E>
                     with public comment periods, and NMFS approval of the FMP amendments and issuance of a final rule.
                </P>
                <P>Fishermen are not guaranteed future participation in a fishery, sector, or component within a sector regardless of when they obtained their permits or of their level of participation in the fishery, sector, or component within a sector before or after the control date under consideration. The Council subsequently may choose a different control date, or they may propose different management approaches without using a control date. The Council also may choose to take no further action to propose measures to control entry or access to the Federal for-hire components of the recreational sectors of the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, or South Atlantic snapper-grouper fisheries.</P>
                <P>Interested participants should locate and preserve records that substantiate and verify their participation in the Federal for-hire components of the recreational sectors of the Atlantic coastal migratory pelagics, Atlantic dolphin and wahoo, or South Atlantic snapper-grouper fisheries. </P>
                <EXTRACT>
                    <FP>
                        (Authority: 16 U.S.C. 1801 
                        <E T="03">et seq.</E>
                        )
                    </FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Samuel D. Rauch, III,</NAME>
                    <TITLE>Deputy Assistant Administrator for Regulatory Programs, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02509 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </PRORULE>
    </PRORULES>
    <VOL>89</VOL>
    <NO>27</NO>
    <DATE>Thursday, February 8, 2024</DATE>
    <UNITNAME>Notices</UNITNAME>
    <NOTICES>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8641"/>
                <AGENCY TYPE="F">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Initiation of Antidumping and Countervailing Duty Administrative Reviews</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) has received requests to conduct administrative reviews of various antidumping duty (AD) and countervailing duty (CVD) orders with December anniversary dates. In accordance with Commerce's regulations, we are initiating those administrative reviews.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable February 8, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Brenda E. Brown, AD/CVD Operations, Customs Liaison Unit, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230, telephone: (202) 482-4735.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>Commerce has received timely requests, in accordance with 19 CFR 351.213(b), for administrative reviews of various AD and CVD orders with December anniversary dates.</P>
                <P>All deadlines for the submission of various types of information, certifications, or comments or actions by Commerce discussed below refer to the number of calendar days from the applicable starting time.</P>
                <HD SOURCE="HD1">Respondent Selection</HD>
                <P>
                    In the event that Commerce limits the number of respondents for individual examination for administrative reviews initiated pursuant to requests made for the orders identified below, Commerce intends to select respondents based on U.S. Customs and Border Protection (CBP) data for U.S. imports during the period of review (POR). We intend to place the CBP data on the record within five days of publication of the initiation notice and to make our decision regarding respondent selection within 35 days of publication of the initiation 
                    <E T="04">Federal Register</E>
                     notice. Comments regarding the CBP data and respondent selection should be submitted within seven days after the placement of the CBP data on the record of this review. Parties wishing to submit rebuttal comments should submit those comments within five days after the deadline for the initial comments.
                </P>
                <P>
                    In the event that Commerce decides it is necessary to limit individual examination of respondents and conduct respondent selection under section 777A(c)(2) of the Tariff Act of 1930, as amended (the Act), the following guidelines regarding collapsing of companies for purposes of respondent selection will apply. In general, Commerce has found that determinations concerning whether particular companies should be “collapsed” (
                    <E T="03">e.g.,</E>
                     treated as a single entity for purposes of calculating AD rates) require a substantial amount of detailed information and analysis, which often require follow-up questions and analysis. Accordingly, Commerce will not conduct collapsing analyses at the respondent selection phase of this review and will not collapse companies at the respondent selection phase unless there has been a determination to collapse certain companies in a previous segment of this AD proceeding (
                    <E T="03">e.g.,</E>
                     investigation, administrative review, new shipper review, or changed circumstances review). For any company subject to this review, if Commerce determined, or continued to treat, that company as collapsed with others, Commerce will assume that such companies continue to operate in the same manner and will collapse them for respondent selection purposes. Otherwise, Commerce will not collapse companies for purposes of respondent selection.
                </P>
                <P>Parties are requested to (a) identify which companies subject to review previously were collapsed, and (b) provide a citation to the proceeding in which they were collapsed. Further, if companies are requested to complete the Quantity and Value (Q&amp;V) Questionnaire for purposes of respondent selection, in general, each company must report volume and value data separately for itself. Parties should not include data for any other party, even if they believe they should be treated as a single entity with that other party. If a company was collapsed with another company or companies in the most recently completed segment of this proceeding where Commerce considered collapsing that entity, complete Q&amp;V data for that collapsed entity must be submitted.</P>
                <HD SOURCE="HD1">Notice of No Sales</HD>
                <P>
                    With respect to AD administrative reviews, we intend to rescind the review where there are no suspended entries for a company or entity under review and/or where there are no suspended entries under the company-specific case number for that company or entity. Where there may be suspended entries, if a producer or exporter named in this notice of initiation had no exports, sales, or entries during the POR, it may notify Commerce of this fact within 30 days of publication of this notice in the 
                    <E T="04">Federal Register</E>
                     for Commerce to consider how to treat suspended entries under that producer's or exporter's company-specific case number.
                </P>
                <HD SOURCE="HD1">Deadline for Withdrawal of Request for Administrative Review</HD>
                <P>Pursuant to 19 CFR 351.213(d)(1), a party that has requested a review may withdraw that request within 90 days of the date of publication of the notice of initiation of the requested review. The regulation provides that Commerce may extend this time if it is reasonable to do so. Determinations by Commerce to extend the 90-day deadline will be made on a case-by-case basis.</P>
                <HD SOURCE="HD1">Deadline for Particular Market Situation Allegation</HD>
                <P>
                    Section 504 of the Trade Preferences Extension Act of 2015 amended the Act by adding the concept of a particular market situation (PMS) for purposes of constructed value under section 773(e) of the Act.
                    <SU>1</SU>
                    <FTREF/>
                     Section 773(e) of the Act states that “if a particular market situation exists such that the cost of materials and fabrication or other processing of any kind does not accurately reflect the cost of production in the ordinary course of trade, the 
                    <PRTPAGE P="8642"/>
                    administering authority may use another calculation methodology under this subtitle or any other calculation methodology.” When an interested party submits a PMS allegation pursuant to section 773(e) of the Act, Commerce will respond to such a submission consistent with 19 CFR 351.301(c)(2)(v). If Commerce finds that a PMS exists under section 773(e) of the Act, then it will modify its dumping calculations appropriately.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Trade Preferences Extension Act of 2015, Public Law 114-27, 129 Stat. 362 (2015).
                    </P>
                </FTNT>
                <P>Neither section 773(e) of the Act nor 19 CFR 351.301(c)(2)(v) set a deadline for the submission of PMS allegations and supporting factual information. However, in order to administer section 773(e) of the Act, Commerce must receive PMS allegations and supporting factual information with enough time to consider the submission. Thus, should an interested party wish to submit a PMS allegation and supporting new factual information pursuant to section 773(e) of the Act, it must do so no later than 20 days after submission of initial responses to section D of the questionnaire.</P>
                <HD SOURCE="HD1">Separate Rates</HD>
                <P>In proceedings involving non-market economy (NME) countries, Commerce begins with a rebuttable presumption that all companies within the country are subject to government control and, thus, should be assigned a single AD deposit rate. It is Commerce's policy to assign all exporters of merchandise subject to an administrative review in an NME country this single rate unless an exporter can demonstrate that it is sufficiently independent so as to be entitled to a separate rate.</P>
                <P>
                    To establish whether a firm is sufficiently independent from government control of its export activities to be entitled to a separate rate, Commerce analyzes each entity exporting the subject merchandise. In accordance with the separate rates criteria, Commerce assigns separate rates to companies in NME cases only if respondents can demonstrate the absence of both 
                    <E T="03">de jure</E>
                     and 
                    <E T="03">de facto</E>
                     government control over export activities.
                </P>
                <P>
                    All firms listed below that wish to qualify for separate rate status in the administrative reviews involving NME countries must complete, as appropriate, either a Separate Rate Application or Certification, as described below. For these administrative reviews, in order to demonstrate separate rate eligibility, Commerce requires entities for whom a review was requested, that were assigned a separate rate in the most recent segment of this proceeding in which they participated, to certify that they continue to meet the criteria for obtaining a separate rate. The Separate Rate Certification form will be available on Commerce's website at 
                    <E T="03">https://access.trade.gov/Resources/nme/nme-sep-rate.html</E>
                     on the date of publication of this 
                    <E T="04">Federal Register</E>
                     notice. In responding to the certification, please follow the “Instructions for Filing the Certification” in the Separate Rate Certification. Separate Rate Certifications are due to Commerce no later than 30 calendar days after publication of this 
                    <E T="04">Federal Register</E>
                     notice. The deadline and requirement for submitting a Separate Rate Certification applies equally to NME-owned firms, wholly foreign-owned firms, and foreign sellers who purchase and export subject merchandise to the United States.
                </P>
                <P>
                    Entities that currently do not have a separate rate from a completed segment of the proceeding 
                    <SU>2</SU>
                    <FTREF/>
                     should timely file a Separate Rate Application to demonstrate eligibility for a separate rate in this proceeding. In addition, companies that received a separate rate in a completed segment of the proceeding that have subsequently made changes, including, but not limited to, changes to corporate structure, acquisitions of new companies or facilities, or changes to their official company name,
                    <SU>3</SU>
                    <FTREF/>
                     should timely file a Separate Rate Application to demonstrate eligibility for a separate rate in this proceeding. The Separate Rate Application will be available on Commerce's website at 
                    <E T="03">https://access.trade.gov/Resources/nme/nme-sep-rate.html</E>
                     on the date of publication of this 
                    <E T="04">Federal Register</E>
                     notice. In responding to the Separate Rate Application, refer to the instructions contained in the application. Separate Rate Applications are due to Commerce no later than 30 calendar days after publication of this 
                    <E T="04">Federal Register</E>
                     notice. The deadline and requirement for submitting a Separate Rate Application applies equally to NME-owned firms, wholly foreign-owned firms, and foreign sellers that purchase and export subject merchandise to the United States.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Such entities include entities that have not participated in the proceeding, entities that were preliminarily granted a separate rate in any currently incomplete segment of the proceeding (
                        <E T="03">e.g.,</E>
                         an ongoing administrative review, new shipper review, 
                        <E T="03">etc.</E>
                        ) and entities that lost their separate rate in the most recently completed segment of the proceeding in which they participated.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Only changes to the official company name, rather than trade names, need to be addressed via a Separate Rate Application. Information regarding new trade names may be submitted via a Separate Rate Certification.
                    </P>
                </FTNT>
                <P>Exporters and producers must file a timely Separate Rate Application or Certification if they want to be considered for individual examination. Furthermore, exporters and producers who submit a Separate Rate Application or Certification and subsequently are selected as mandatory respondents will no longer be eligible for separate rate status unless they respond to all parts of the questionnaire as mandatory respondents.</P>
                <HD SOURCE="HD2">Initiation of Reviews:</HD>
                <P>In accordance with 19 CFR 351.221(c)(1)(i), we are initiating administrative reviews of the following AD and CVD orders and findings. We intend to issue the final results of these reviews not later than December 31, 2024.</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s200,15">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">
                            Period to
                            <LI>be reviewed</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="21">
                            <E T="02">AD Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            FRANCE: Strontium Chromate,
                            <SU>4</SU>
                             A-427-830
                        </ENT>
                        <ENT>11/1/22-10/31/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">Société Nouvelle des Couleurs Zinciques</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">INDIA: Carbazole Violet Pigments 23, A-533-838</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">Gharda Chemicals, Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">Meghmani Pigments</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">Navpad Pigments Pvt. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Stainless Steel Flanges from India, A-533-877</ENT>
                        <ENT>10/1/22-9/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            CD Industries (Prop. Kisaan Engineering Works Pvt. Ltd.) 
                            <SU>5</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">JAPAN: Non-Oriented Electrical Steel, A-588-872</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">Nippon Steel Corporation</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8643"/>
                        <ENT I="01">OMAN: Circular Welded Carbon-Quality Steel Pipe, A-523-812</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">
                            Al Jazeera Steel Products Co. SAOG 
                            <SU>6</SU>
                        </ENT>
                        <ENT>12/1/21-11/30/22</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">REPUBLIC OF KOREA:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Certain Superabsorbent Polymers, A-580-914</ENT>
                        <ENT>6/7/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">LG Chem, Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Forged Steel Fittings, A-580-904</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Samyoung Fitting Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Welded Line Pipe, A-580-876</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Husteel Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hyundai Steel Company</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">NEXTEEL Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">SeAH Steel Corporation</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">THE PEOPLE'S REPUBLIC OF CHINA:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Cased Pencils, A-570-827</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Apc International Air&amp;Sea Freight</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Kang Jie Kong Cargo Agent</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Machinery Imp. &amp; Exp.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Majestic Stationery Co.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Wallong Imp. &amp; Exp. Cor</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">China First Pencil Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo Homey Union Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Orient Internatioanal Logistics</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Orient International Enterprise Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Orient International Holding</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Orient International Logistics Hol</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shandong Wah Yuen Stationery Co. Ltd.; Wah Yuen Stationery Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Everest International Logistics Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Foreigntrade Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sts International Corp.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Tianjin Tonghe Stationery Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuxi Nice International Trading Co.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Crystalline Silicon Photovoltaic Cells, Whether Or Not Assembled Into Modules, A-570-979</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Anji DaSol Solar Energy Science &amp; Technology Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Boviet Solar Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">BYD (Shangluo) Industrial Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">BYD H.K. Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Canadian Solar International Limited; Canadian Solar Manufacturing (Changshu) Inc.; Canadian Solar Manufacturing (Luoyang) Inc.; CSI Cells Co., Ltd.; CSI Solar Power (China) Inc.; CSI-GCL Solar Manufacturing (Yancheng) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Canadian Solar Manufacturing, Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Changzhou Trina PV Ribbon Materials Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint Energy (Haining) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint Solar (Hong Kong) Company Limited; Chint Solar (Jiuquan) Co., Ltd.; Chint Solar (Zhejiang) Co., Ltd.; Chint New Energy Technology (Haining) Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Modules (DaFeng) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Solar Co., Ltd. (f.k.a. CSI Solar Power (China) Inc.)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Solar Manufacturing (Fu Ning) Co., Ltd. (f.k.a. CSI-GCL Solar Manufacturing (YanCheng) Co., Ltd.)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Solar Power Group Co., Ltd. (f.k.a. CSI Solar Power (China) Inc.)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">De-Tech Trading Limited HK</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hengdian Group DMEGC Magnetics Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hongkong Hello Tech Energy Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiawei Solarchina (Shenzhen) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiawei Solarchina Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">JingAo Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar (Malaysia) Sdn. Bhd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar Import and Export Co., Ltd.; Jinko Solar Co., Ltd.; JinkoSolar Technology (Haining) Co., Ltd.; Yuhuan Jinko Solar Co., Ltd.; Zhejiang Jinko Solar Co., Ltd.; Jiangsu Jinko Tiansheng Solar Co., Ltd.; JinkoSolar (Chuzhou) Co., Ltd.; JinkoSolar (Yiwu) Co., Ltd.; JinkoSolar (Shangrao) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar International Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar Technology Sdn. Bhd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinkosolar Middle East DMCC</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Lightway Green New Energy Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Longi (HK) Trading Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Longi Solar Technology Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Luoyang Suntech Power Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Maodi Solar Technology (Dongguan) Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">New East Solar Energy Cambodia Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo ETDZ Holdings, Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo Qixin Solar Electrical Appliance Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Red Sun Energy Long An Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Renesola Jiangsu Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">ReneSola Zhejiang Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8644"/>
                        <ENT I="05" O="xl">Risen Energy Co. Ltd.; Risen Energy (Changzhou) Co., Ltd.; Risen (Wuhai) New Energy Co., Ltd.; Zhejiang Twinsel Electronic Technology Co., Ltd.; Risen (Luoyang) New Energy Co., Ltd.; Jiujiang Shengchao Xinye Technology Co., Ltd.; Jiujiang Shengzhao Xinye Trade Co., Ltd.; Ruichang Branch, Risen Energy (HongKong) Co., Ltd.; Risen Energy (YIWU) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Risen Solar Technology Sdn. Bhd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai BYD Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai JA Solar Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Nimble Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Glory Industries Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Sungold Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Topray Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Yingli New Energy Resources Co., Ltd.; Baoding Jiasheng Photovoltaic Technology Co., Ltd.; Baoding Tianwei Yingli New Energy Resources Co., Ltd.; Beijing Tianneng Yingli New Energy Resources Co., Ltd.; Hainan Yingli New Energy Resources Co., Ltd.; Hengshui Yingli New Energy Resources Co., Ltd.; Lixian Yingli New Energy Resources Co., Ltd.; Tianjin Yingli New Energy Resources Co., Ltd.; Yingli Energy (China) Company</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sumec Hardware &amp; Tools Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Suntech Power Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Taizhou BD Trade Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">tenKsolar (Shanghai) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar (Singapore) Science and Technology Pte. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar Co., Ltd.; Trina Solar (Changzhou) Science and Technology Co., Ltd.; Yancheng Trina Guoneng Photovoltaic Technology Co., Ltd.; Changzhou Trina Solar Yabang Energy Co., Ltd.; Turpan Trina Solar Energy Co., Ltd.; Hubei Trina Solar Energy Co., Ltd.; Trina Solar (Hefei) Science and Technology Co., Ltd.; Changzhou Trina Hezhong Photoelectric Co., Ltd.; Changzhou Trina PV Ribbon Materials Co., Ltd.; Trina Solar (Changzhou) Science and Technology Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar Energy Development Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar Energy Development PTE Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar Science &amp; Technology (Thailand) Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Vina Cell Technology Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Vina Solar Technology Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuxi Suntech Power Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuxi Tianran Photovoltaic Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Xiamen Yiyusheng Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yingli Green Energy International Trading Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Aiko Solar Energy Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Mattresses, A-570-092</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dockter China Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongguan Beijianing Household Products Co., Ltd. (a.k.a. Better Zs, Ltd.)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongguan Sinohome Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Chiland Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan City Jinxingma Furniture Manufacture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan City Kewei Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan City Shunde Haozuan Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Coir Mat Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan EON Technology Industry Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Mengruo Household Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Qisheng Sponge Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Ruixin Non Woven Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Suilong Furniture Co. Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Foshan Ziranbao Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Guangdong Diglant Furniture Industrial Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Healthcare Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hong Kong Gesin Technology Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Huizhou Lemeijia Household Products Co., Ltd. (a.k.a. Better Zs, Ltd.)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Wellcare Household Articles Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiashan Nova Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiaxing Taien Springs Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiaxing Visco Foam Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinlongheng Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">lnno Sports Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Luen Tai Global Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Luen Tai Group (China) Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Man Wah Furniture Manufacturing (Hui Zhou) Co., Ltd., Man Wah (MACAO Commercial Offshore), Ltd. and Man Wah (USA), Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo Megafeat Bedding Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo Shuibishen Home Textile Technology Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Nisco Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Quanzhou Hengang Imp. &amp; Exp. Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Quanzhou Hengang Industries Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Glory Home Furnishings Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen L&amp;T Industrial Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sinomax (Zhejiang) Polyurethane Technology Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sinomax Macao Commercial Offshore Limited</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8645"/>
                        <ENT I="05" O="xl">Healthcare Sleep Products Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wings Developing Co., Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Xianghe Kaneman Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Xilinmen Furniture Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Glory Home Furnishings Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zinus Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zinus Xiamen Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zinus Zhangzhou Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Multilayered Wood Flooring, A-570-970</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Anhui Longhua Bamboo Product Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Benxi Flooring Factory (General Partnership)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Benxi Wood Company</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalian Deerfu Wooden Product Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalien Jaenmaken Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalian Jiahong Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalian Shengyu Science and Technology Development Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalian Shumaike Floor Manufacturing Co., Ltd.; Dalian Penghong Floor Products Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongtai Fuan Universal Dynamics, LLC</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dunhua City Dexin Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dunhua City Hongyuan Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dun Hua Sen Tai Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dunhua Shengda Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">HaiLin LinJing Wooden Products, Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hunchun Xingjia Wooden Flooring Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Huzhou Chenghang Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Huzhou Fulinmen Imp. &amp; Exp. Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Huzhou Sunergy World Trade Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Guyu International Trading Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Keri Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Mingle Flooring Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Senmao Bamboo and Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Simba Flooring Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Yuhui International Trade Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiashan HuiJiaLe Decoration Material Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiashan On-Line Lumber Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiaxing Hengtong Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Kahrs AB</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Kingman Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Lauzon Distinctive Hardwood Flooring, Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Linyi Anying Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Linyi Youyou Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Metropolitan Hardwood Floors, Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Muchsee Wood (Chuzhou) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Pinge Timber Manufacturing (Zhejiang) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Power Dekor Group Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sino-Maple (Jiangsu) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Suzhou Dongda Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Tongxiang Jisheng Import and Export Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yekalon Industry Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yihua Lifestyle Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yingyi-Nature (Kunshan) Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Dadongwu Greenhome Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Fuerjia Wooden Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Longsen Lumbering Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Shiyou Timber Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Shuimojiangnan New Material Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Simite Wooden Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Refillable Stainless Steel Kegs, A-570-093</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Guangzhou Jingye Machinery Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Guangzhou Ulix Industrial &amp; Trading Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">UNITED ARAB EMIRATES: Circular Welded Carbon-Quality Steel Pipe, A-520-807</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            Ajmal Steel Tubes &amp; Pipes Ind. L.L.C.
                            <SU>7</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Conares Metal Supply Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">KHK Scaffolding and Formwork LLC;</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">THL Tube and Pipe Industries LLC;</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            Universal Tube and Plastic Industries Ltd.
                            <SU>8</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">CVD Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">INDIA: Carbazole Violet Pigment 23, C-533-839</ENT>
                        <ENT>1/1/22-12/31/22</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Gharda Chemicals, Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Meghmani Pigments</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Navpad Pigments Pvt. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">THE PEOPLE'S REPUBLIC OF CHINA:</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8646"/>
                        <ENT I="03">Crystalline Silicon Photovoltaic Cells, Whether Or Not Assembled Into Modules, C-570-980</ENT>
                        <ENT>1/1/22-12/31/22</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Anji DaSol Solar Energy Science &amp; Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Astronergy Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Astronergy Solar</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Baoding Jiasheng Photovoltaic Technology Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Baoding Tianwei Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Beijing Tianneng Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Boviet Solar Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">BYD (Shangluo) Industrial Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">BYD H.K. Co</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Canadian Solar (USA) Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Canadian Solar Inc.; Canadian Solar Manufacturing (Luoyang) Inc.; CSI Cells Co., Ltd.; CSI New Energy Holding Co., Ltd.; CSI Solar Manufacture Inc.; CSI Solar Power (China) Inc.; CSI Solar Technologies Inc.; CSI Solartronics (Changshu) Co., Ltd.; CANADIAN SOLAR MANUFACTURING (CHANGSHU) INC.; CSI-GCL Solar Manufacturing (Yancheng) Co., Ltd.; Changshu Tegu New Materials Technology Co., Ltd.; Changshu Tlian Co., Ltd.; Suzhou Sanysolar Materials Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Canadian Solar International Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Changzhou Trina Hezhong Photoelectric Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Changzhou Trina Solar Yabang Energy Co., Ltd.; Hubei Trina Solar Energy Co., Ltd.; Trina Solar (Changzhou) Science and Technology Co., Ltd.; Turpan Trina Solar Energy Co., Ltd.; Yancheng Trina Solar Energy Technology Co., Ltd.; Changzhou Trina Solar Energy Co., Ltd.; Trina Solar Co., Ltd.; Changzhou Trina PV Ribbon Materials Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint New Energy Technology (Haining) Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint Solar (Hong Kong) Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint Solar (Jiuquan) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Chint Solar (Zhejiang) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Modules (Dafeng) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">CSI Solar Manufacturing (Fu Ning) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">DelSolar (Wujiang) Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">DelSolar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">De-Tech Trading Limited HK</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongguan Sunworth Solar Energy Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Donghai JA Solar Technology Co., Ltd.; Hebei Ningjin Songgong Semiconductor Co., Ltd.; Hebei Ningtong Electronic Materials Co., Ltd.; Hebei Yujing Electronic Science and Technology Co., Ltd.; Hefei JA Solar Technology Co., Ltd.; JA (Hefei) Renewable Energy Co., Ltd; Jing Hai Yang Semiconductor Material (Donghai) Co., Ltd.; JingAo Solar Co., Ltd.; JA SOLAR TECHNOLOGY YANGZHOU CO., LTD.; Shanghai JA Solar Technology Co., Ltd.; JA Solar Investment China Co., Ltd; Donghai JingAo Solar Energy Science and Technology Co., Ltd.; Solar Silicon Valley Electronic Science and Technology Co., Ltd.; Beijing Jinfeng Investment Co., Ltd.; Ningjin Songgong Electronic Materials Co., Ltd.; Jinglong Industry and Commerce Group Co., Ltd.; Ningjin County Jingyuan New Energy Investment Co., Ltd.; Hebei Jinglong New Materials Technology Group Co., Ltd.; Hebei Jinglong Sun Equipment Co. Ltd.; Hebei Jingle Optoelectronic Technology Co., Ltd.; Ningjin Jingxing Electronic Material Co., Ltd.; Ningjin Saimei Ganglong Electronic Materials Co., Ltd.; Hebei Ningtong Electronic Materials Co., Ltd.; JA Solar (Xingtai) Co., Ltd.; Xingtai Jinglong Electronic Material Co., Ltd.; Xingtai Jinglong PV Materials Co., Ltd.; JA PV Technology Co., Ltd.; Ningjin Jinglong PV Industry Investment Co., Ltd.; Baotou JA Solar Technology Co., Ltd.; Xingtai Jinglong New Energy Co., Ltd.; Ningjin County Jing Tai Fu Technology Co., Ltd.; JA Solar Technology Co., Ltd.; Jinglong Technology Holdings Co., Ltd.; Ningjin Guiguang Electronics Investment Co., Ltd.; Ningjin Longxin Investment Co., Ltd.; Beijing JA Solar PV Technology Co., Ltd.; Solar Silicon Peak Electronic Science and Technology Co., Ltd.; Jingwei Electronic Materials Co., Ltd.; Taicang Juren PV Material Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Eoplly New Energy Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">ERA Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">ET Solar Energy Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Fuzhou Sunmodo New Energy Equipment Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">GCL System Integration Technology Co. Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hainan Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hangzhou Sunny Energy Science and Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hengdian Group DMEGC Magnetics Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hengshui Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">High Hope Zhongtian Corporation (High Hope Zhongtian)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu High Hope Int'l Group</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Jinko Tiansheng Solar Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Suhui Asset Management Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar Import And Export Co., Ltd.; Jinko Solar Co., Ltd.; Zhejiang Jinko Solar Co., Ltd.; Jiangxi Jinko Photovoltaic Materials Co., Ltd.; Xinjiang Jinko Solar Co., Ltd.; JinkoSolar (Chuzhou) Co., Ltd.; JinkoSolar (Shangrao) Co., Ltd.; JinkoSolar (Sichuan) Co., Ltd.; JinkoSolar (Yiwu) Co., Ltd.; JinkoSolar Technology (Haining) Co., Ltd.; Ruixu Industrial Co., Ltd.; Yuhuan Jinko Solar Co., Ltd.; Jinko Solar (Shanghai) Management Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jinko Solar International Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Lightway Green New Energy Co., Ltd.; Light Way Green New Energy Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Lixian Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Longi (HK) Trading Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">LONGi Solar Technology Co., Ltd.; LERRI Solar Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Luoyang Suntech Power Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8647"/>
                        <ENT I="05" O="xl">Nice Sun PV Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Ningbo ETDZ Holdings, Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">ReneSola Jiangsu Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Renesola Zhejiang Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Risen Energy Co., Ltd.; Risen (Wuhai) New Energy Co., Ltd.; Zhejiang Twinsel Electronic Technology Co., Ltd.; Risen (Luoyang) New Energy Co., Ltd.; Jiujiang Shengzhao Xinye Technology Co., Ltd.; Jiujiang Shengchao Xinye Trade Co., Ltd.; Ruichang Branch; Risen Energy (HongKong) Co., Ltd.; Risen Energy (Changzhou) Co., Ltd.; Risen Energy (Yiwu) Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Risen Solar Technology Sdn. Bhd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai BYD Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Nimble Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Sungold Solar Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Topray Solar Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sumec Hardware &amp; Tools Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sunpreme Solar Technology (Jiaxing) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Suntech Power Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Suntimes Technology Co., Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Systemes Versilis, Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Taimax Technologies Inc</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Taizhou BD Trade Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Talesun Energy</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Talesun Solar</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">tenKsolar (Shanghai) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Tianjin Yingli New Energy Resources Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Toenergy Technology Hangzhou Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar (Hefei) Science and Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Trina Solar Science &amp; Technology (Thailand) Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuxi Suntech Power Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuxi Tianran Photovoltaic Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yingli Energy (China) Company Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yingli Green Energy International Trading Company Limited</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang ERA Solar Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Sunflower Light Energy Science &amp; Technology Limited Liability Company</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Mobile Access Equipment and Subassemblies Thereof, C-570-140</ENT>
                        <ENT>1/1/22-12/31/22</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Anhui Heli Industrial Vehicle Imp. &amp; Exp. Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Changzhou Hengxuan Logistics Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Crown Equipment (Suzhou) Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Deqing Liguan Machinery Trading Co. Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongguan Tinbo Packing Industrial Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Everocean International Forwarding Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Guangxi LiuGong Machinery Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Guangzhou Eounice Machinery Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hangzhou Hengli Metal Processing Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Hunan Sinoboom Intelligent Equipment Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiaxing Xinfeng Zhong Wang Hydrualic Pressure Accessory Factory</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Leader Technology Co., Ltd</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            Lingong Group Jinan Heavy Machinery Co., Ltd.
                            <SU>9</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Mantall Heavy Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Noblelift Intelligent Equipment Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Oshkosh JLG (Tianjin) Equipment Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Sany Marine Heavy Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shandong Tavol Machinery Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Full Trans Global Forwarding Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Inter Cooperation Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Xiangcheng Trading Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shanghai Xindun Trade Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Shenzhen Shining Ocean International Logistics Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Skyjack Inc</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Terex (Changzhou) Machinery Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Wuhai Huadong Heavy Industry Foundry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Xuzhou Construction Machinery Group Fire-Fighting Safety Equipment Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Xuzhou Construction Machinery Group Imp. &amp; Exp. Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Yantai Carhart Manufacturing Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            Zhejiang Dingli Machinery Co., Ltd.
                            <SU>10</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Smile Tools Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Multilayered Wood Flooring, C-570-971</ENT>
                        <ENT>1/1/22-12/31/22</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Benxi Flooring Factory (General Partnership)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Benxi Wood Company</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dalian Jaenmaken Wood Industry Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Dongtai Fuan Universal Dynamics, LLC</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">HaiLin LinJing Wooden Products Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8648"/>
                        <ENT I="05" O="xl">Hunchun Xingjia Wooden Flooring Inc.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Huzhou Fulinmen Imp. &amp; Exp. Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiangsu Mingle Flooring Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Jiashan On-Line Lumber Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">
                            Riverside Plywood Corporation; Baroque Timber Industries (Zhongshan) Co., Ltd.; Suzhou Times Flooring Co., Ltd.; Zhongshan Lianjia Flooring Co., Ltd. 
                            <SU>11</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Suzhou Dongda Wood Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Tongxiang Jisheng Import and Export Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Longsen Lumbering Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05" O="xl">Zhejiang Shiyou Timber Co., Ltd.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Suspension Agreements</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">MEXICO:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Sugar, A-201-845</ENT>
                        <ENT>12/1/22-11/30/23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Sugar, C-201-846</ENT>
                        <ENT>1/1/23-12/31/23</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                     
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         In the notice of 
                        <E T="03">Initiation of Antidumping and Countervailing Duty Administrative Reviews,</E>
                         88 FR 90168 (December 29, 2023) for AD and CVD orders with November anniversary dates, Commerce inadvertently omitted the AD order on Strontium Chromate from France. Commerce hereby initiates the administrative review of this order and intends to complete this review within the statutory timeframe relevant to orders with November anniversary months.
                    </P>
                    <P>
                        <SU>5</SU>
                         In the notice of 
                        <E T="03">Initiation of Antidumping and Countervailing Duty Administrative Reviews,</E>
                         88 FR 88 FR 84784 (December 6, 2023) for AD and CVD orders with October anniversary dates, this company was incorrectly listed as “CD Industries; Kisaan Engineering Works Pvt. Ltd.”
                    </P>
                    <P>
                        <SU>6</SU>
                         Pursuant to 19 CFR 351.213(c), Commerce deferred initiation of the 2021-2022 administrative review for one year at the request of Al Jazeera Steel Products Co. SAOG. 
                        <E T="03">See</E>
                          
                        <E T="03">Initiation of Antidumping and Countervailing Duty Administrative Reviews,</E>
                         88 FR 7060, 7068 (February 2, 2023). Commerce did not receive any requests for review for the 2022-2023 review period.
                    </P>
                    <P>
                        <SU>7</SU>
                         Commerce previously determined that Ajmal Steel Tubes &amp; Pipes Ind. L.L.C. and Ajmal Steel Tubes &amp; Pipes Ind. L.L.C.-Branch-1 should be treated as a single entity. 
                        <E T="03">See Circular Welded Carbon-Quality Steel Pipe from the United Arab Emirates: Final Results of Antidumping Duty Administrative Review; 2019-2020,</E>
                         87 FR 41111 (July 11, 2022) (
                        <E T="03">CWP from UAE 2019-20</E>
                        ). Therefore, we are initiating this administrative review with respect to both companies within the collapsed entity.
                    </P>
                    <P>
                        <SU>8</SU>
                         In prior reviews, Commerce treated these companies as a single entity. 
                        <E T="03">See, e.g., CWP from UAE 2019-20.</E>
                         Absent information to the contrary, we are treating these companies as a single entity for the purpose of this administrative review.
                    </P>
                    <P>
                        <SU>9</SU>
                         Commerce previously found Linyi Lingong Machinery Group Co., Ltd. to be a cross-owned affiliate of Lingong Group Jinan Heavy Machinery Co., Ltd. 
                        <E T="03">See Certain Mobile Access Equipment and Subassemblies Thereof from the People's Republic of China: Final Affirmative Countervailing Duty Determination,</E>
                         86 FR 57809 (October 19, 2021) (
                        <E T="03">MAE from China Final Determination</E>
                        ). Accordingly, we are initiating this review with respect to Linyi Lingong Machinery Group Co., Ltd. and its cross-owned entity, Lingong Group Jinan Heavy Machinery Co., Ltd., listed in this notice.
                    </P>
                    <P>
                        <SU>10</SU>
                         Commerce previously found Zhejiang Green Power Machinery Co., Ltd. and Shengda Fenghe Automotive Equipment Co., Ltd. to be cross-owned affiliates of Zhejiang Dingli Machinery Co., Ltd. 
                        <E T="03">See MAE from China Final Determination.</E>
                         Accordingly, we are initiating this review with respect to Zhejiang Green Power Machinery Co., Ltd. and its cross-owned entities, Zhejiang Dingli Machinery Co., Ltd. and Shengda Fenghe Automotive Equipment Co., Ltd., listed in this notice.
                    </P>
                    <P>
                        <SU>11</SU>
                         Commerce previously found Baroque Timber Industries (Zhongshan) Co., Ltd., Suzhou Times Flooring Co., Ltd., and Zhongshan Lianjia Flooring Co., Ltd. to be cross-owned affiliates of Riverside Plywood Corporation 
                        <E T="03">see e.g., Multilayered Wood Flooring from the People's Republic of China: Final Results of Countervailing Duty Administrative Review; 2020,</E>
                         88 FR 34828 (May 31, 2023). Accordingly, we are initiating this review with respect to Riverside Plywood Corporation and its cross-owned entities listed in this notice.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Duty Absorption Reviews</HD>
                <P>During any administrative review covering all or part of a period falling between the first and second or third and fourth anniversary of the publication of an AD order under 19 CFR 351.211 or a determination under 19 CFR 351.218(f)(4) to continue an order or suspended investigation (after sunset review), Commerce, if requested by a domestic interested party within 30 days of the date of publication of the notice of initiation of the review, will determine whether ADs have been absorbed by an exporter or producer subject to the review if the subject merchandise is sold in the United States through an importer that is affiliated with such exporter or producer. The request must include the name(s) of the exporter or producer for which the inquiry is requested.</P>
                <HD SOURCE="HD1">Gap Period Liquidation</HD>
                <P>
                    For the first administrative review of any order, there will be no assessment of antidumping or countervailing duties on entries of subject merchandise entered, or withdrawn from warehouse, for consumption during the relevant “gap” period of the order (
                    <E T="03">i.e.,</E>
                     the period following the expiry of provisional measures and before definitive measures were put into place), if such a gap period is applicable to the POR.
                </P>
                <HD SOURCE="HD1">Administrative Protective Orders and Letters of Appearance</HD>
                <P>
                    Interested parties must submit applications for disclosure under administrative protective orders in accordance with the procedures outlined in Commerce's regulations at 19 CFR 351.305. Those procedures apply to administrative reviews included in this notice of initiation. Parties wishing to participate in any of these administrative reviews should ensure that they meet the requirements of these procedures (
                    <E T="03">e.g.,</E>
                     the filing of separate letters of appearance as discussed at 19 CFR 351.103(d)).
                </P>
                <HD SOURCE="HD1">Factual Information Requirements</HD>
                <P>
                    Commerce's regulations identify five categories of factual information in 19 CFR 351.102(b)(21), which are summarized as follows: (i) evidence submitted in response to questionnaires; (ii) evidence submitted in support of allegations; (iii) publicly available information to value factors under 19 CFR 351.408(c) or to measure the adequacy of remuneration under 19 CFR 351.511(a)(2); (iv) evidence placed on the record by Commerce; and (v) evidence other than factual information described in (i)-(iv). These regulations require any party, when submitting factual information, to specify under which subsection of 19 CFR 351.102(b)(21) the information is being submitted and, if the information is submitted to rebut, clarify, or correct factual information already on the record, to provide an explanation identifying the information already on the record that the factual information seeks to rebut, clarify, or correct. The regulations, at 19 CFR 351.301, also provide specific time limits for such factual submissions based on the type of factual information being submitted. 
                    <PRTPAGE P="8649"/>
                    Please review the 
                    <E T="03">Final Rule,</E>
                    <SU>12</SU>
                    <FTREF/>
                     available at 
                    <E T="03">https://www.govinfo.gov/content/pkg/FR-2013-07-17/pdf/2013-17045.pdf,</E>
                     prior to submitting factual information in this segment. Note that Commerce has amended certain of its requirements pertaining to the service of documents in 19 CFR 351.303(f).
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See Certification of Factual Information To Import Administration During Antidumping and Countervailing Duty Proceedings,</E>
                         78 FR 42678 (July 17, 2013) (
                        <E T="03">Final Rule</E>
                        ); 
                        <E T="03">see also</E>
                         the frequently asked questions regarding the 
                        <E T="03">Final Rule,</E>
                         available at 
                        <E T="03">https://enforcement.trade.gov/tlei/notices/factual_info_final_rule_FAQ_07172013.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">Administrative Protective Order, Service, and Other Procedures in Antidumping and Countervailing Duty Proceedings; Final Rule,</E>
                         88 FR 67069 (September 29, 2023).
                    </P>
                </FTNT>
                <P>
                    Any party submitting factual information in an AD or CVD proceeding must certify to the accuracy and completeness of that information using the formats provided at the end of the 
                    <E T="03">Final Rule.</E>
                    <SU>14</SU>
                    <FTREF/>
                     Commerce intends to reject factual submissions in any proceeding segments if the submitting party does not comply with applicable certification requirements.
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         
                        <E T="03">See</E>
                         section 782(b) of the Act; 
                        <E T="03">see also Final Rule;</E>
                         and the frequently asked questions regarding the 
                        <E T="03">Final Rule,</E>
                         available at 
                        <E T="03">https://enforcement.trade.gov/tlei/notices/factual_info_final_rule_FAQ_07172013.pdf.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Extension of Time Limits Regulation</HD>
                <P>
                    Parties may request an extension of time limits before a time limit established under Part 351 expires, or as otherwise specified by Commerce.
                    <SU>15</SU>
                    <FTREF/>
                     In general, an extension request will be considered untimely if it is filed after the time limit established under Part 351 expires. For submissions which are due from multiple parties simultaneously, an extension request will be considered untimely if it is filed after 10:00 a.m. on the due date. Examples include, but are not limited to: (1) case and rebuttal briefs, filed pursuant to 19 CFR 351.309; (2) factual information to value factors under 19 CFR 351.408(c), or to measure the adequacy of remuneration under 19 CFR 351.511(a)(2), filed pursuant to 19 CFR 351.301(c)(3) and rebuttal, clarification and correction filed pursuant to 19 CFR 351.301(c)(3)(iv); (3) comments concerning the selection of a surrogate country and surrogate values and rebuttal; (4) comments concerning CBP data; and (5) Q&amp;V questionnaires. Under certain circumstances, Commerce may elect to specify a different time limit by which extension requests will be considered untimely for submissions which are due from multiple parties simultaneously. In such a case, Commerce will inform parties in the letter or memorandum setting forth the deadline (including a specified time) by which extension requests must be filed to be considered timely. This policy also requires that an extension request must be made in a separate, stand-alone submission, and clarifies the circumstances under which Commerce will grant untimely-filed requests for the extension of time limits. Please review the 
                    <E T="03">Final Rule,</E>
                     available at 
                    <E T="03">https://www.gpo.gov/fdsys/pkg/FR-2013-09-20/html/2013-22853.htm,</E>
                     prior to submitting factual information in these segments.
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.302.
                    </P>
                </FTNT>
                <P>These initiations and this notice are in accordance with section 751(a) of the Act (19 U.S.C. 1675(a)) and 19 CFR 351.221(c)(1)(i).</P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>James Maeder,</NAME>
                    <TITLE>Deputy Assistant Secretary for Antidumping and Countervailing Duty Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02600 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-549-848]</DEPDOC>
                <SUBJECT>Truck and Bus Tires From Thailand: Postponement of Preliminary Determination in the Less-Than-Fair-Value Investigation</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable February 8, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Faris Montgomery or Jonathan Schueler, AD/CVD Operations, Office VIII, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-1537 and (202) 482-9175, respectively.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On November 6, 2023, the U.S. Department of Commerce (Commerce) initiated a less-than-fair-value (LTFV) investigation of imports of truck and bus tires from Thailand.
                    <SU>1</SU>
                    <FTREF/>
                     Currently, the preliminary determination is due no later than March 25, 2024.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Truck and Bus Tires from Thailand: Initiation of Less-Than-Fair-Value Investigation,</E>
                         88 FR 77960 (November 14, 2023).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Postponement of Preliminary Determination</HD>
                <P>Section 733(b)(1)(A) of the Tariff Act of 1930, as amended (the Act), requires Commerce to issue the preliminary determination in an LTFV investigation within 140 days after the date on which Commerce initiated the investigation. However, section 733(c)(1) of the Act permits Commerce to postpone the preliminary determination until no later than 190 days after the date on which Commerce initiated the investigation if: (A) the petitioner makes a timely request for a postponement; or (B) Commerce concludes that the parties concerned are cooperating, that the investigation is extraordinarily complicated, and that additional time is necessary to make a preliminary determination. Under 19 CFR 351.205(e), the petitioner must submit a request for postponement 25 days or more before the scheduled date of the preliminary determination and must state the reasons for the request. Commerce will grant the request unless it finds compelling reasons to deny the request.</P>
                <P>
                    On November 27, 2023, the petitioner 
                    <SU>2</SU>
                    <FTREF/>
                     submitted a timely request that Commerce postpone the preliminary determination in the LTFV investigation.
                    <SU>3</SU>
                    <FTREF/>
                     The petitioner stated that it requested postponement due to the “complexity of the issues presented in this investigation.” 
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The petitioner is the United Steel, Paper and Forestry, Rubber, Manufacturing, Energy, Allied Industrial and Service Workers International Union, AFL-CIO, CLC.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Petitioner's Letter, “Request to Extend the Preliminary Determination,” dated November 27, 2023.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>
                    For the reason stated above and because there are no compelling reasons to deny the request, Commerce, in accordance with section 733(c)(1)(A) of the Act, is postponing the deadline for the preliminary determination by 50 days (
                    <E T="03">i.e.,</E>
                     190 days after the date on which this investigation was initiated). As a result, Commerce will issue its preliminary determination no later than May 14, 2024. In accordance with section 735(a)(1) of the Act and 19 CFR 351.210(b)(1), the deadline for the final determination of this investigation will continue to be 75 days after the date of the preliminary determination, unless postponed at a later date.
                </P>
                <P>This notice is issued and published pursuant to section 733(c)(2) of the Act and 19 CFR 351.205(f)(1).</P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Abdelali Elouaradia,</NAME>
                    <TITLE>Deputy Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02601 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8650"/>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XD719]</DEPDOC>
                <SUBJECT>North Pacific Fishery Management Council; Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of web conference.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The North Pacific Fishery Management Council (Council) Bering Sea Fishery Ecosystem Plan Climate Change Taskforce will meet February 26, 2024.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on Monday, February 26, 2024, from 9 a.m. to 4 p.m. Alaska time.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be a web conference. Join online through the link at 
                        <E T="03">https://meetings.npfmc.org/Meeting/Details/3036.</E>
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         North Pacific Fishery Management Council, 1007 W 3rd Ave., Suite 400, Anchorage, AK 99501-2252; telephone: (907) 271-2809. Instructions for attending the meeting are given under 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                        , below.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Dr. Diana Stram, Council staff; phone: (907) 271-2809 and email: 
                        <E T="03">diana.stram@noaa.gov.</E>
                         For technical support, please contact our administrative staff; email: 
                        <E T="03">npfmc.admin@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Agenda</HD>
                <HD SOURCE="HD2">Monday, February 26, 2024</HD>
                <P>
                    The agenda will include: (a) discuss agenda and case studies for Climate Scenarios workshop; (b) ideas for futher outreach for workshop and next steps; and (c) other business. The agenda is subject to change, and the latest version will be posted at 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/3036</E>
                     prior to the meeting, along with meeting materials.
                </P>
                <HD SOURCE="HD1">Connection Information</HD>
                <P>
                    You can attend the meeting online using a computer, tablet, or smart phone; or by phone only. Connection information will be posted online at: 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/3036.</E>
                </P>
                <HD SOURCE="HD1">Public Comment</HD>
                <P>
                    Public comment letters will be accepted and should be submitted electronically to 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/3036.</E>
                </P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Rey Israel Marquez,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02617 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XD716]</DEPDOC>
                <SUBJECT>Gulf of Mexico Fishery Management Council; Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Gulf of Mexico Fishery Management Council (Council) will hold a two day in-person meeting of its Standing, Reef Fish, Socioeconomic, and Ecosystem Scientific and Statistical Committees (SSC).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held Tuesday, February 27 and Wednesday, February 28, 2024; 8:30 a.m.-5 p.m. EST.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will take place at the Gulf Council office. Registration information will be available on the Council's website by visiting 
                        <E T="03">www.gulfcouncil.org</E>
                         and clicking on the “meeting tab”.
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         Gulf of Mexico Fishery Management Council, 4107 W Spruce Street, Suite 200, Tampa, FL 33607; telephone: (813) 348-1630.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Ryan Rindone, Lead Fishery Biologist, Gulf of Mexico Fishery Management Council; 
                        <E T="03">ryan.rindone@gulfcouncil.org,</E>
                         telephone: (813) 348-1630.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Tuesday, February 27, 2024; 8:30 a.m.-5 p.m., EST</HD>
                <P>The meeting will begin with Introductions and Adoption of Agenda, Scope of Work, review and approval of Minutes and Meeting Summary from the September and October 2023 SSC meetings.</P>
                <P>
                    Following, the SSC will review SEDAR 85: Gulf of Mexico Yellowedge Grouper, including presentations, fishermen feedback, and background documentation to support SSC discussion. The SSC will then review a Comparison of the 
                    <E T="03">Reef Fish</E>
                     and 
                    <E T="03">Snapper Grouper</E>
                     Fisheries of the Southeaster US, followed by a consideration of Deep-water 
                    <E T="03">Grouper</E>
                     Landings Data and Catch Limits. Public comment will be heard at the end of the day.
                </P>
                <HD SOURCE="HD1">Wednesday, February 28, 2024; 8:30 a.m.-5 p.m., EST</HD>
                <P>
                    The SSC will review and discuss the SEDAR 74: Gulf of Mexico 
                    <E T="03">Red Snapper</E>
                     Research Track, followed by a review of SEDAR Process Recommendations from SEDAR 74. Next, the SSC will discuss the SEDAR 96: Southeastern US 
                    <E T="03">Yellowtail Snapper</E>
                     Operational Assessment Terms of Reference and Participants for Recreational Data Tropical Working Group. The SSC will then review SEDAR 85: Gulf of Mexico 
                    <E T="03">Yellowedge Grouper</E>
                     Projections, followed by a discussion of Revised 
                    <E T="03">Black Grouper</E>
                     and 
                    <E T="03">Yellowfin Grouper</E>
                     Landings and Catch Limits. Lastly, the SSC will review the 2024 Gulf of Mexico 
                    <E T="03">Red Grouper</E>
                     Interim Analysis, which will not include catch advice. Public comment will be heard at the end of the day before any items under Other Business are discussed.
                </P>
                <HD SOURCE="HD3">—Meeting Adjourns</HD>
                <P>
                    The meeting will also be broadcast via webinar. You may register for the webinar by visiting 
                    <E T="03">www.gulfcouncil.org</E>
                     and clicking on the SSC meeting on the calendar.
                </P>
                <P>
                    The Agenda is subject to change, and the latest version along with other meeting materials will be posted on 
                    <E T="03">www.gulfcouncil.org</E>
                     as they become available.
                </P>
                <P>Although other non-emergency issues not on the agenda may come before the Scientific and Statistical Committees for discussion, in accordance with the Magnuson-Stevens Fishery Conservation and Management Act, those issues may not be the subject of formal action during this meeting. Actions of the Scientific and Statistical Committee will be restricted to those issues specifically identified in the agenda and any issues arising after publication of this notice that require emergency action under Section 305(c) of the Magnuson-Stevens Fishery Conservation and Management Act, provided the public has been notified of the Council's intent to take-action to address the emergency.</P>
                <HD SOURCE="HD1">Special Accommodations</HD>
                <P>These meetings are physically accessible to people with disabilities. Requests for sign language interpretation or other auxiliary aid should be directed to Kathy Pereira, (813) 348-1630, at least 5 days prior to the meeting date.</P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <PRTPAGE P="8651"/>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Rey Israel Marquez,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02616 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XD705]</DEPDOC>
                <SUBJECT>Pacific Fishery Management Council; Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Pacific Fishery Management Council's (Pacific Council) Ad Hoc Ecosystem Workgroup (EWG) is holding an online meeting, which is open to the public.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The online meeting will be held on Tuesday, February 27, 2024, from 9 a.m. to 2 p.m., Pacific time or until the business of the meeting is completed.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This meeting will be held online. Specific meeting information, including directions on how to join the meeting and system requirements will be provided in the meeting announcement on the Pacific Council's website (see 
                        <E T="03">www.pcouncil.org</E>
                        ). You may send an email to Mr. Kris Kleinschmidt (
                        <E T="03">kris.kleinschmidt@noaa.gov</E>
                        ) or contact him at (503) 820-2412 for technical assistance.
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         Pacific Fishery Management Council, 7700 NE Ambassador Place, Suite 101, Portland, OR 97220-1384.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Kit Dahl, Staff Officer, Pacific Council; telephone: (503) 820-2422.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The primary purpose of this online meeting is to provide briefings for Pacific Council advisory body members and the public on two topics on the Pacific Council's March 5-11, 2024, meeting agenda. The first briefing will present the 2023-2024 California Current Ecosystem Status Report. The second briefing will cover the EWG's recommendations on work under the Pacific Council's Fishery Ecosystem Plan Initiative 4, which explores ways to integrate climate and ecosystem information into Pacific Council fishery management processes. In addition to providing these briefings, the EWG may discuss other matters related to its work for the Pacific Council.</P>
                <P>Although non-emergency issues not contained in the meeting agenda may be discussed, those issues may not be the subject of formal action during this meeting. Action will be restricted to those issues specifically listed in this document and any issues arising after publication of this document that require emergency action under section 305(c) of the Magnuson-Stevens Fishery Conservation and Management Act, provided the public has been notified of the intent to take final action to address the emergency.</P>
                <HD SOURCE="HD1">Special Accommodations</HD>
                <P>
                    Requests for sign language interpretation or other auxiliary aids should be directed to Mr. Kris Kleinschmidt (
                    <E T="03">kris.kleinschmidt@noaa.gov;</E>
                     (503) 820-2412) at least 10 days prior to the meeting date.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Rey Israel Marquez,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02615 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">COMMODITY FUTURES TRADING COMMISSION</AGENCY>
                <SUBJECT>Sunshine Act Meetings</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">FEDERAL REGISTER CITATION OF PREVIOUS ANNOUNCEMENT:</HD>
                    <P> 89 FR 7381, February 2, 2024.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PREVIOUSLY ANNOUNCED TIME AND DATE OF THE MEETING: </HD>
                    <P>9:00 a.m. EST, Friday, February 9, 2024.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CHANGES IN THE MEETING: </HD>
                    <P>The time of the meeting has changed. This meeting will now start at 1:00 p.m. EST. The matters to be considered have also changed. Instead of enforcement and examination matters, as previously announced, only enforcement matters will now be considered. The meeting date, place, and Closed status, as previously announced, remain unchanged.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION: </HD>
                    <P>Christopher Kirkpatrick, 202-418-5964.</P>
                    <P>
                        <E T="03">Authority:</E>
                         5 U.S.C. 552b.
                    </P>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Christopher Kirkpatrick,</NAME>
                    <TITLE>Secretary of the Commission.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02635 Filed 2-6-24; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 6351-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <SUBJECT>Final Environmental Impact Statement for the O'Brien Road Access Modernization, Fort Meade, Maryland</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The DoD announces the availability of the Final Environmental Impact Statement (EIS) as part of the environmental planning process for the O'Brien Road Access Modernization (ORAM) project at Fort George G. Meade, Maryland (hereafter referred to as Fort Meade). The DoD proposes to implement the ORAM project, which would entail renovation and upgrade of inspection facilities, upgrade of access facilities, and corresponding roadway improvements for Mapes, O'Brien, Perimeter, and Venona Roads on Fort Meade.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments must be received by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments can be submitted by mail to “ORAM EIS” c/o HDR, 2650 Park Tower Drive, Suite 400, Vienna, VA 22180 or by email to 
                        <E T="03">ORAM@hdrinc.com.</E>
                    </P>
                    <P>
                        Copies of the Final EIS are available on the project website at 
                        <E T="03">https://www.nab.usace.army.mil/oram</E>
                         and at the Medal of Honor Memorial Library, 4418 Llewellyn Avenue, Fort Meade, MD 20755; Glen Burnie Regional Library, 1010 Eastway, Glen Burnie, MD 21060; Odenton Regional Library, 1325 Annapolis Road, Odenton, MD 21113; and Severn Community Library, 2624 Annapolis Road, Severn, Maryland 21144. You may also call (301) 688-2970 or send an email to 
                        <E T="03">ORAM@hdrinc.com</E>
                         to request a copy of the Final EIS.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Jeffrey Williams at 301-688-2970, or email 
                        <E T="03">jdwill2@nsa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The purpose of the proposed project is to construct facilities and infrastructure to allow for increased capacity for required security processing of traffic and deliveries entering Fort Meade and the National Security Agency (NSA) campus. The need for the proposed project is to address inefficiencies with current infrastructure and capacity issues.</P>
                <P>The Final EIS is available for a 30-day period following publication of the Notice of Availability.</P>
                <SIG>
                    <PRTPAGE P="8652"/>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02612 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEFENSE NUCLEAR FACILITIES SAFETY BOARD</AGENCY>
                <SUBJECT>Recommendation 2023-01</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Defense Nuclear Facilities Safety Board.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; recommendation.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Defense Nuclear Facilities Safety Board has made a Recommendation to the Secretary of Energy concerning the U.S. Department of Energy's (DOE) regulatory safety framework related to onsite transportation and safety deficiencies in Los Alamos National Laboratory's transportation safety document. Pursuant to the requirements of the Atomic Energy Act of 1954, as amended, the Defense Nuclear Facilities Safety Board is publishing the Recommendation and associated correspondence with DOE and requesting comments from interested members of the public.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments, data, views, or arguments concerning the recommendation are due on or by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Send comments concerning this notice to: Defense Nuclear Facilities Safety Board, 625 Indiana Avenue NW, Suite 700, Washington, DC 20004-2001. Comments may also be submitted by email to 
                        <E T="03">comment@dnfsb.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Tara Tadlock, Associate Director for Board Operations, Defense Nuclear Facilities Safety Board, 625 Indiana Avenue NW, Suite 700, Washington, DC 20004-2901, (800) 788-4016.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Recommendation 2023-1 to the Secretary of Energy</HD>
                <HD SOURCE="HD2">Onsite Transportation Safety</HD>
                <HD SOURCE="HD3">Pursuant to 42 U.S.C. 2286a(b)(5)</HD>
                <HD SOURCE="HD3">Atomic Energy Act of 1954, As Amended</HD>
                <P>
                    <E T="03">Introduction.</E>
                     The Defense Nuclear Facilities Safety Board (Board) has evaluated Los Alamos National Laboratory's (LANL) safety basis for onsite transportation, detailed in the laboratory's transportation safety document (TSD); the safe harbors 
                    <SU>1</SU>
                    <FTREF/>
                     for onsite transportation of radioactive materials identified in the U.S. Department of Energy's (DOE) Nuclear Safety Management rule, 10 Code of Federal Regulations (CFR) Part 830; and the ability of DOE's safety oversight framework to identify and correct safety issues with its safe harbors and the TSDs at its defense nuclear facilities.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Table 1 of Appendix A to Subpart B of 10 CFR 830 lists acceptable methodologies for developing safety analyses to meet requirements in 10 CFR 830. Such methodologies are referred to as “safe harbors.” Throughout this document the phrase “onsite transportation safe harbors” refers to both DOE Order 460.1D, Hazardous Materials Packaging and Transportation Safety, and DOE Guide 460.1-1, Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety, as they relate to the preparation of an onsite TSD for radioactive materials that are not of national security interest.
                    </P>
                </FTNT>
                <P>The Board identified safety weaknesses in LANL's onsite TSD, stemming in part from weaknesses in the safe harbors that govern TSD development, and communicated its safety concerns to the Secretary of Energy in a January 6, 2022, letter. The National Nuclear Security Administration's (NNSA) management and operating contractor at LANL, Triad National Security, LLC, implemented compensatory safety measures for onsite transportation of radioactive materials in March 2023, following a letter of direction from the NNSA Los Alamos Field Office (NA-LA). Triad formally incorporated the compensatory measures into revisions of the LANL TSD and technical safety requirements (TSR), which NA-LA approved in August 2023, with two conditions of approval (COA) [2]. These measures and COAs represent an improvement to the safety of onsite transportation of radioactive materials at LANL; however, more work is necessary to ensure the LANL TSD appropriately identifies all hazards, analyzes all pertinent accident scenarios, and evaluates the effectiveness of all credited safety controls.</P>
                <P>NA-LA had approved Triad's deficient TSD on the basis that it met the applicable safe harbors for safety analysis identified in 10 CFR 830. Until DOE revises the safe harbors for onsite transportation of radioactive materials to provide clear and effective safety requirements, the risk remains that LANL or other defense nuclear sites may regress to inadequate TSDs that fail to provide an effective set of safety controls. The Board has concluded the following:</P>
                <P>(1) The recently approved compensatory safety measures are welcomed; however, the LANL TSD requirements and their implementation do not ensure that onsite transportation activities at LANL are conducted in a manner that ensures adequate protection of public health and safety;</P>
                <P>(2) The requirements of the safe harbors do not ensure that onsite transportation activities are conducted in a manner that ensures adequate protection of public health and safety; and</P>
                <P>(3) DOE failed to address known safety deficiencies in its safe harbors for onsite transportation of radioactive materials and neglected to take timely action to correct the safety issues with the LANL TSD.</P>
                <P>
                    <E T="03">Background.</E>
                     10 CFR 830 specifies that onsite transportation of radioactive materials at DOE sites may be conducted either in accordance with Department of Transportation (DOT) regulations or under a specific type of documented safety analysis (DSA) known as a TSD. Table 1 in Appendix A to Subpart B of 10 CFR 830 identifies the following safe harbor methodology for preparing DSAs/TSDs for onsite transportation activities:
                </P>
                <P>• Preparing a Safety Analysis Report for Packaging in accordance with DOE Order 460.1A, Packaging and Transportation Safety, October 2, 1996, or successor document; and</P>
                <P>• Preparing a Transportation Safety Document in accordance with DOE Guide 460.1-1, Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety, June 5, 1997, or successor document.</P>
                <P>Following a safety review of the LANL TSD, the Board identified safety issues with both the LANL TSD and the onsite transportation safe harbors in 10 CFR 830. The Board documented these safety issues in a letter to the Secretary of Energy dated January 6, 2022. DOE responded on September 13, 2022, stating its agreement with, and plans to address, the Board's safety concerns. However, DOE's response only partially addressed the safety concerns identified by the Board. Furthermore, DOE did not ensure that LANL took timely action to implement compensatory measures at LANL that are needed to provide adequate protection of workers and the public during onsite transportation activities in the absence of an adequate TSD.</P>
                <P>
                    <E T="03">Analysis.</E>
                     Attachment B, Findings, Supporting Data, and Analysis, provides additional detail and supporting analysis for this recommendation, the conclusions of which are discussed below.
                </P>
                <P>
                    <E T="03">LANL Transportation Safety Document</E>
                    —10 CFR 830 defines a DSA (including TSDs) as “a documented analysis of the extent to which a nuclear facility can be operated safely with respect to workers, the public, and the 
                    <PRTPAGE P="8653"/>
                    environment, including a description of the conditions, safe boundaries, and hazard controls that provide the basis for ensuring safety” [3]. The LANL TSD has fundamental flaws in critical safety areas and thus does not demonstrate that members of the public and workers are adequately protected during onsite transportation activities.
                </P>
                <P>The LANL TSD does not adequately (1) identify all potential hazards, (2) analyze accident scenarios, and (3) demonstrate the effectiveness of its safety control set. These safety issues are particularly concerning given the high material-at-risk (MAR) allowed by the TSD, the proximity of LANL's onsite transportation routes to the public, and the nature of several credible accident scenarios. These factors result in high calculated unmitigated dose consequences to the public without an adequate safety control strategy. On January 31, 2023, Triad informed NA-LA that it would implement compensatory safety measures by late March 2023 and would submit a revised TSD with updated TSRs by June 1, 2023. Triad implemented the compensatory measures procedurally on March 31, 2023, and submitted a revised TSD and TSRs that incorporated those measures to NA-LA for approval on June 1, 2023. NA-LA approved the revised TSD and TSRs on August 10, 2023, with two COAs which require Triad to address additional NA-LA comments in the 2023 and 2024 annual update of the TSD and TSRs [2]. The compensatory measures and COAs improve the safety of LANL onsite transportation operations and partially address the LANL-specific safety issues that the Board raised in January 2022. Therefore, DOE should ensure that Triad continues to implement these compensatory measures until it develops a TSD in full compliance with 10 CFR 830 that would resolve the safety issues of adequate protection identified in this recommendation.</P>
                <P>
                    <E T="03">Onsite Transportation Directives</E>
                    —The Board identified four primary safety concerns with the DOE directives related to onsite transportation. First, the onsite transportation safe harbors do not contain all applicable requirements from 10 CFR 830; therefore, they do not ensure that TSDs meet all 10 CFR 830 requirements. In DOE's response to the Board's January 6, 2022, letter, DOE asserted that 10 CFR 830 requirements apply “regardless of the methodology for DSA development that is used,” and that, consequently, 10 CFR 830 requirements do not need to flow down into the onsite transportation safe harbors [4]. DOE's assertion is inconsistent with the role of safe harbors, which is to provide an approved DSA methodology such that if a contractor follows the safe harbors, then all the requirements of 10 CFR 830 will be fulfilled. This concern is illustrated by the LANL TSD: although the LANL TSD follows the safe harbor methodology specified in 10 CFR 830, it fails to properly derive hazard controls necessary to ensure adequate protection of workers and the public. Additionally, the lack of requirements in the safe harbors has led sites across DOE's defense nuclear facilities complex to seek supplementary guidance from other documents. Specifically, several sites supplement guidance from the onsite transportation safe harbors with methodologies from DOE Standard 3009-94 Change Notice 3, Preparation Guide for U.S. Department of Energy Nonreactor Nuclear Facility Documented Safety Analyses, for development and analysis of unique, bounding accident scenarios, including quantitative analysis [5]. Examples include the 2011 Hanford TSD, the 2015 Lawrence Livermore National Laboratory (LLNL) TSD, and the 2017 Nevada National Security Site (NNSS) TSD. The sites' reliance on methods from another safe harbor to adequately evaluate accident conditions highlights the weakness of the onsite transportation safe harbors in meeting 10 CFR 830 requirements, particularly related to the evaluation of accident conditions.
                </P>
                <P>
                    Second, the onsite transportation safe harbors do not provide specific criteria against which to deterministically evaluate the effectiveness of the safety control set, leading to an incomplete understanding of the risk of onsite transportation operations.
                    <SU>2</SU>
                    <FTREF/>
                     Instead, they require that TSDs demonstrate an equivalent level of safety to DOT and Nuclear Regulatory Commission (NRC) regulations for offsite transportation. However, the onsite transportation safe harbors do not provide a clear definition of equivalent safety. In DOE's response to the Board's January 6, 2022, letter, DOE acknowledged that an improved methodology “to better document analyses of equivalent safety” was warranted and committed to providing better guidance [4]. DOE has not provided a timeline for that new guidance in its response, nor in any subsequent communication.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         By way of comparison, the safe harbor for DOE nonreactor nuclear facilities, DOE Standard 3009-2014, Preparation of Nonreactor Nuclear Safety Documented Safety Analysis, applies the concept of an evaluation guideline (25 rem total effective dose for a member of the offsite public), which “the safety analysis evaluates against,” and “is established for the purpose of identifying the need for and evaluating safety controls” [16].
                    </P>
                </FTNT>
                <P>
                    Third, the onsite transportation safe harbors do not provide guidance on methods to control public access during onsite transfers conducted under TSDs. Restricting public access is important from both regulatory and safety perspectives, because onsite transfers may use roads open to the public. If public access is not properly restricted, the public could be closer to onsite transportation activities than intended. Members of the public could initiate an accident (
                    <E T="03">e.g.,</E>
                     vehicle crash) and could receive a higher radiation dose by being in the vicinity of a transport accident if a release occurred. Additionally, the onsite transportation safe harbors do not provide detailed guidance on controlling onsite traffic of site personnel. Similar to the concern with members of the public, site personnel traveling onsite in government or personal vehicles could initiate an accident during onsite transfers of radioactive material. At LANL in particular, the high operational tempo needed to accomplish its greatly expanded pit manufacturing mission will inevitably increase onsite traffic. Therefore, it is incumbent upon DOE to develop requirements and guidance on the control of site traffic during onsite transfers of radioactive material to ensure TSDs adequately address that hazard.
                </P>
                <P>Finally, DOE Standard 1104-2016, Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents, does not contain specific guidance for federal review and approval of TSDs. As a result, DOE oversight personnel do not have specific criteria to evaluate whether a TSD ensures safety and complies with the onsite transportation safe harbors, as they would have for a DOE Standard 3009-compliant DSA. In response to the Board's January 6, 2022, letter, DOE stated it would “review DOE-STD-1104 to determine whether improvements are warranted” [4]. DOE's response did not provide a timeline for that evaluation. To ensure adequate and consistent reviews by DOE oversight personnel across the defense nuclear complex, DOE should add review and approval criteria specific to TSDs to DOE Standard 1104-2016.</P>
                <P>
                    <E T="03">DOE Oversight</E>
                    —DOE and NNSA failed to independently identify deficiencies in the onsite transportation safe harbors and the LANL TSD. Additionally, DOE and NNSA did not ensure that timely corrective actions were taken when the Board identified transportation safety concerns and have struggled to resolve safety concerns 
                    <PRTPAGE P="8654"/>
                    when collaboration across program offices is required.
                </P>
                <P>DOE issued DOE Guide 460.1-1, the 10 CFR 830 safe harbor methodology for preparing TSDs, in 1997 and has not updated it since. Practitioners at DOE's defense nuclear facilities have at least tacitly recognized the deficiencies in the guide for many years. As discussed above, several sites use DOE Standard 3009-94 to supplement the onsite transportation safe harbors in developing their TSDs.</P>
                <P>Additionally, NNSA did not resolve safety issues with the LANL TSD. In 2007, an NNSA safety basis review team identified several of the safety issues discussed in this Recommendation. Personnel from the NNSA Packaging Certification Division, who were part of the safety basis review team, “concluded that the TSD as submitted did not provide an adequate level of analysis to support the conclusions that for non DOT compliant packages the overall transport system provided an equivalent level of safety” [6]. To address these issues, NA-LA directed the contractor to provide quantitative analysis, which was included in subsequent revisions of the TSD. However, in Revision 9, which became effective in November 2012, the LANL management and operating contractor completely rewrote the safety analysis, removing the quantitative analysis. When approving the 2012 revision, and each subsequent revision, NA-LA failed to identify the safety issues that had previously been corrected. Additionally, NNSA's Office of Packaging and Transportation conducted an assessment of LANL's packaging and transportation program in July 2015. This assessment provided an opportunity for NNSA to identify the weaknesses in the LANL TSD, but it did not. Finally, DOE's response to the Board's January 6, 2022, letter, stated that “NNSA uses the Biennial Review process to review field office performance in meeting requirements for the review and approval of TSDs” [4]. However, these biennial reviews did not identify the weaknesses in NA-LA's review and approval of the LANL TSD.</P>
                <P>The Board brought the safety concerns with the LANL TSD and the onsite transportation safe harbors to DOE's attention in its January 6, 2022, letter; however, DOE did not take timely action to address them. It took more than a year for LANL to implement any compensatory measures to address the Board's safety concerns. More than ten months passed before NA-LA transmitted a letter requesting that Triad consider a wide-ranging list of potential compensatory measures. NA-LA considered Triad's first response on December 9, 2022, unsatisfactory. After additional discussions between Triad and NA-LA personnel, Triad sent a new letter to NA-LA on January 31, 2023, in which Triad agreed to implement a set of compensatory measures that represented an improvement to the safety posture of onsite transportation operations. It is noteworthy, however, that Triad's letter did not acknowledge that the compensatory measures were needed to address any safety issues.</P>
                <P>Further, given the safety concerns identified with the onsite transportation safe harbor and LANL TSD, DOE would greatly benefit from conducting a complete extent of condition review of all sites' TSDs. While the DOE Office of Environmental Management did conduct an extent of condition review for a subset of sites under its purview in 2021, it was done before the Board's letter highlighted the specific safety issues, and therefore the review's scope and approach were not informed by the Board's conclusions. Moreover, the review was not formally documented.</P>
                <P>Finally, the Board is concerned with DOE's ability to address safety issues that require collaboration across program offices. DOE's September 13, 2022, letter that responded to the Board's January 6, 2022, letter acknowledged that DOE would need to evaluate “how we communicate across offices, engage with the field, and share operating experiences across the Department.” The Board concurs with DOE's recognition and need for such an evaluation, and for DOE to take corrective actions to ensure effective collaboration in developing appropriate requirements in the revised onsite transportation safe harbors.</P>
                <P>In summary, DOE's historical management of the safe harbors for onsite transportation of radioactive materials and the LANL TSD in particular indicates deficiencies in DOE's ability, as the regulatory authority, to recognize transportation safety issues and ensure that timely action is taken to address them.</P>
                <P>
                    <E T="03">Recommendations.</E>
                     To ensure adequate protection during onsite transportation activities at DOE sites with defense nuclear facilities, the Board recommends that DOE carry out the following actions, organized by topical area below:
                </P>
                <HD SOURCE="HD3">1. LANL Transportation Safety Document</HD>
                <P>a. Revise the LANL TSD to address the safety concerns identified in this Recommendation and to comply with a revised safe harbor methodology per sub-Recommendation 2.a.</P>
                <P>b. Ensure compensatory safety measures remain in place until implementation of the LANL TSD revised per sub-Recommendation 1.a above.</P>
                <HD SOURCE="HD3">2. Onsite Transportation Directives</HD>
                <P>
                    a. Rewrite DOE safe harbors for onsite transportation—DOE Order 460.1D, 
                    <E T="03">Hazardous Materials Packaging and Transportation Safety,</E>
                     and DOE Guide 460.1-1, 
                    <E T="03">Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety</E>
                    —to:
                </P>
                <P>i. Provide requirements and guidance to ensure TSDs comply with all applicable 10 CFR 830 safety basis requirements including requirements related to accident evaluation and hazard controls.</P>
                <P>ii. Include robust evaluation criteria to ensure TSDs demonstrate that safety controls are effective at reducing risk.</P>
                <P>iii. Include implementation guidance for restricting public access to transportation routes, and controlling onsite traffic, during onsite transportation of radioactive materials.</P>
                <P>
                    b. Change DOE Standard 1104, 
                    <E T="03">Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents,</E>
                     to incorporate requirements and guidance for DOE review and approval of TSDs.
                </P>
                <P>c. Conduct an extent of condition review of TSDs for DOE sites with defense nuclear facilities to identify any near-term actions necessary to ensure safety until the safe harbors are revised and implemented.</P>
                <HD SOURCE="HD3">3. DOE Oversight</HD>
                <P>a. Perform an independent causal analysis for the safety issues identified in this Recommendation, including the effectiveness of DOE oversight of contractor TSDs, DOE's management of its onsite transportation directives, and DOE's evaluation of and actions in response to the safety issues identified in prior Board correspondence on onsite transportation safety. Identify and implement corrective actions to address appropriate causal analysis results that preclude recurrence of the safety issues.</P>
                <FP>Joyce L. Connery</FP>
                <FP>Chair</FP>
                <HD SOURCE="HD1">Attachment A—Risk Assessment for Draft Recommendation 2023-1</HD>
                <EXTRACT>
                    <P>In making its recommendations to the Secretary of Energy and in accordance with 42 United States Code (U.S.C.) 2286a.(b)(5), the Defense Nuclear Facilities Safety Board (Board) shall consider, and specifically assess risk (whenever sufficient data exists). This risk assessment supports Recommendation 2023-1, Onsite Transportation Safety. The Board's Policy Statement 5, Policy Statement on Assessing Risk, states:</P>
                    <PRTPAGE P="8655"/>
                    <P>Risk assessments performed in accordance with the Board's revised enabling statute will aid the Secretary of Energy in the development of implementation plans focused on the safety improvements that are needed to address the Board's recommendations.</P>
                    <P>This recommendation identifies safety issues with (1) the Los Alamos National Laboratory (LANL) transportation safety document (TSD), (2) the Department of Energy's (DOE) onsite transportation safe harbors that contain the methodology for development of the safety basis for onsite transportation of radioactive materials, and (3) inadequate oversight from DOE and the National Nuclear Security Administration (NNSA) in identifying and addressing these deficiencies and safety issues.</P>
                    <P>Development of a safety basis is one of the primary mechanisms by which DOE ensures adequate protection of workers and the public. To that end, DOE Policy 420.1, Department of Energy Nuclear Safety Policy, states that DOE is committed to “[e]stablishing and implementing nuclear safety requirements,” with the “[k]ey nuclear safety elements to be addressed [to] include hazard identification, assessment and control” [7]. The issues identified in Recommendation 2023-1 with regard to the onsite transportation safe harbors demonstrate that DOE has not met this commitment for onsite transportation of radioactive material.</P>
                    <P>Therefore, TSDs that are developed following this methodology may not contain sufficient analysis to establish appropriate hazard controls. This issue is illustrated by the LANL TSD. The LANL TSD does not provide adequate analysis to demonstrate that significant public consequences are not credible and does not identify and analyze various credible hazards.</P>
                    <P>
                        Since the current LANL TSD does not calculate the likelihood and consequence of a vehicle accident, the Board used data from previously approved LANL TSDs. The July 2007 through March 2012 revisions of the LANL TSD contained quantitative analysis of the risk of LANL onsite transportation activities [8]. Those older revisions of the TSD referenced the “Area G Transuranic [TRU] Waste Transportation Accident and Fire” scenario from the Area G safety basis dated April 2003.
                        <SU>3</SU>
                        <FTREF/>
                         In this accident scenario, a vehicle crashes or rolls over, causing a fire and spilling the waste containers [9]. The postulated material-at-risk (MAR) in this scenario was the maximum inventory for a waste transportation truck at the time (about 17.7 kg plutonium 239, or Pu-239, equivalent). The estimated unmitigated dose consequence to the public was about 190 rem total effective dose (TED).
                    </P>
                    <FTNT>
                        <P>
                            <SU>3</SU>
                             The current revision of the Area G safety basis does not include a similar transportation accident scenario.
                        </P>
                    </FTNT>
                    <P>
                        From November 2012 through June 2023, the LANL TSD had a MAR limit of 20 kg Pu-239 equivalent, the corresponding estimated dose consequence to the public is about 217 rem TED. The 2003 Area G accident scenario estimated the unmitigated likelihood of the accident to be 10
                        <E T="51">−</E>
                        <SU>3</SU>
                         instances per year (once per thousand years). Additionally, the July 2007 through March 2012 revisions of the TSD noted that the distance to the site boundary for some onsite transportation routes is closer than the distance to the site boundary for Area G. As a result, as noted in those TSDs, the unmitigated dose consequence for those transportation activities could be substantially higher. The current LANL TSD identifies some engineered controls (
                        <E T="03">e.g.,</E>
                         the package and enclosed cargo compartment 
                        <SU>4</SU>
                        <FTREF/>
                        ) that may provide some confinement in an accident. However, these safety controls are not designed to withstand the hypothetical accident conditions described in the relevant Department of Transportation and Nuclear Regulatory Commission regulations. Therefore, the reduction in risk they provide is not known. Additionally, the current LANL TSD allows for transfers of up to 1.9 kg Pu-239 equivalent without either a package or enclosed cargo compartment.
                    </P>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             An enclosed cargo compartment is “an enclosure with floor, walls on all sides, and a roof in which materials are transferred” [22].
                        </P>
                    </FTNT>
                    <P>
                        The Area G TRU waste transportation and fire accident scenario is just one of many potential onsite transportation accidents at LANL involving significant MAR quantities. From discussions with NNSA Los Alamos Field Office (NA-LA) personnel, the Board understands that LANL averages between 30 and 40 shipments of hazard category 2 quantities 
                        <SU>5</SU>
                        <FTREF/>
                         of material per year.
                    </P>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             This term comes from DOE Standard 1027-1992, Hazard Categorization and Accident Analysis Techniques for Compliance with DOE Order 5480.23, Nuclear Safety Analysis Reports. This standard determines which of four hazard categories—1, 2, 3, or less than 3—applies to a facility, based on the amount of nuclear material it contains. In this case, a hazard category 2 quantity equates to approximately 1 kg or more of plutonium-239, or equivalent.
                        </P>
                    </FTNT>
                    <P>In the TSD and technical safety requirements submitted in June 2023 and approved in August 2023, NNSA's management and operating contractor at LANL, Triad National Security, LLC, established a reduced MAR limit of 8.8 kg Pu-239 equivalent for onsite transfers at LANL [10] [11]. Using this value for the Area G TRU waste transportation accident scenario, the estimated unmitigated dose to the public would be about 96 rem TED.</P>
                    <P>Given the high dose consequence and likelihood of potential accident scenarios for onsite transportation of radioactive materials at LANL, together with the lack of analysis in the LANL TSD to show the effectiveness of safety controls, the Board has determined this recommendation is justified and necessary from a risk perspective.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Attachment B—Findings, Supporting Data, and Analysis</HD>
                <EXTRACT>
                    <P>
                        <E T="03">Background.</E>
                         Department of Energy (DOE) Order 460.1D, Hazardous Materials Packaging and Transportation Safety, states that DOE has “broad authority under the Atomic Energy Act of 1954 (AEA), as amended, to regulate activities involving radioactive materials . . . including the transportation of radioactive materials” [12]. In most cases, DOE uses commercial carriers that are regulated by the Department of Transportation (DOT) and/or the Nuclear Regulatory Commission (NRC). However, in some cases, DOE “exercises its AEA authority to regulate certain Departmental shipments, including . . . onsite transfers” [12].
                    </P>
                    <P>The order also states that onsite transfers of hazardous materials must be conducted in accordance either with “49 CFR [Code of Federal Regulations] Parts 171-180 and the relevant federal regulations governing each mode of transportation,” or a transportation safety document (TSD) [12]. Per DOE Order 460.1D, a “TSD must describe the methodology and compliance process to meet equivalent safety for any deviation from 49 CFR parts 171-180 and 49 CFR parts 350-399” and “[f]or onsite transfers involving nuclear facility Hazard Category 2 or 3 quantities, the TSD must comply with the Safety Basis Requirements of 10 CFR part 830, subpart B” [12].</P>
                    <P>
                        Additionally, 10 CFR 830, Subpart B, requires that each DOE contractor prepare a documented safety analysis (DSA) for transportation activities not covered by DOT regulations. Table 1 in Appendix A of 10 CFR 830, Subpart B, provides the acceptable methodologies for preparing a DSA; these methodologies are called “safe harbors.” For transportation activities not involving materials of national security interest (MNSI),
                        <SU>6</SU>
                        <FTREF/>
                         Table 1 identifies DOE Order 460.1A and DOE Guide 460.1-1, Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety, as the safe harbors [13]. The order contains the methodology for preparing a safety analysis report for packaging, and the guide contains the methodology for preparing a TSD.
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             DOE defines MNSI as “Hazardous materials used in the development, testing, production, and maintenance of nuclear weapons and other materials that have been designated as critical to the national security of the United States” [31].
                        </P>
                    </FTNT>
                    <P>
                        The Defense Nuclear Facilities Safety Board (Board) conducted a safety review of the Los Alamos National Laboratory (LANL) TSD, and identified safety issues with both the LANL TSD and the onsite transportation safe harbors.
                        <SU>7</SU>
                        <FTREF/>
                         The Board communicated these safety concerns in a letter to the Secretary of Energy dated January 6, 2022, and requested that DOE provide a written report and briefing within 120 calendar days (May 6, 2022). On May 12, 2022, DOE responded with a letter stating that it was addressing the Board's safety concerns, but the final report was still in process, and DOE anticipated transmitting the report by July 6, 2022. On September 13, 2022, the Board received DOE's written report, and DOE 
                        <PRTPAGE P="8656"/>
                        briefed the Board on its response on November 4, 2022.
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             Table 1 of Appendix A of 10 CFR 830, Subpart B, lists acceptable methodologies for developing safety analyses to meet requirements in 10 CFR 830. Such directives are referred to as “safe harbors.” Throughout this document the phrase “onsite transportation safe harbors” refers to both DOE Order 460.1D, Hazardous Materials Packaging and Transportation Safety, and DOE Guide 460.1-1, Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety, as they relate to the preparation of an onsite TSD for radioactive materials that are not of national security interest.
                        </P>
                    </FTNT>
                    <P>DOE's September 13, 2022, cover letter stated that DOE agreed with and planned to address the Board's safety concerns. However, the enclosed report only partially addressed the safety concerns identified by the Board. For instance, the response asserted that it was unnecessary to flow down requirements from 10 CFR 830 to the onsite transportation safe harbor, as the requirements apply regardless. However this is inconsistent with the role of safe harbors in 10 CFR 830, which describes them as acceptable methodologies for preparing a DSA (meaning that if a contractor follows the safe harbors, then all the requirements of 10 CFR 830 will be fulfilled). Further, the response acknowledged that DOE's safe harbor for development of safety bases for onsite transportation of radioactive materials was deficient but then incongruously contended that the LANL TSD was acceptable because it met the deficient safe harbor.</P>
                    <P>During this time, the management and operating contractor responsible for the LANL TSD, Triad National Security, LLC (Triad), took no compensatory safety actions to ensure the safety of the public and workers during onsite transfers of radioactive material. On October 11, 2022, the National Nuclear Security Administration's (NNSA) Los Alamos Field Office (NA-LA) sent a memorandum to Triad requesting that it develop an impact assessment of a list of potential compensatory measures, propose revisions to those measures, and propose additional measures, as applicable, within 60 days. Triad responded to the NA-LA memo on December 9, 2022, stating that there would be “minimal impact on cost, scope, and schedule of Laboratory operations,” because “the recommended compensatory measures are already included in the TSD implementation procedures as part of normal day-to-day operations” [14]. Triad further stated that it would provide the revised TSD and associated technical safety requirements (TSR) to NA-LA by June 1, 2023 [14]. In follow-up discussions with Board personnel, NA-LA indicated that Triad's response was unsatisfactory.</P>
                    <P>Following further engagement with NA-LA, Triad sent a new response to NA-LA on January 31, 2023 [15]. It discussed what quantities of radioactive materials would constitute high material-at-risk (MAR) transfers and provided detailed compensatory measures for high MAR transfers. Triad implemented these compensatory measures procedurally on March 31, 2023, and submitted to NA-LA for approval a revised TSD and TSRs which incorporated those measures on June 1, 2023 [1], which NA-LA approved in August 2023, with two conditions of approval (COA) [2].</P>
                    <HD SOURCE="HD2">Findings</HD>
                    <HD SOURCE="HD3">1. LANL Transportation Safety Document</HD>
                    <P>Per 10 CFR 830, the purpose of a DSA (or a TSD, which is a specific type of DSA) is to “provide reasonable assurance that a DOE nuclear facility can be operated safely in a manner that adequately protects workers, the public, and the environment” [3]. Further, DOE Standard 3009-2014 says “although all elements of the DSA preparation are important, three elements—hazard analysis, accident analysis, and hazard control selection—are fundamental, because they determine the hazard controls needed to provide protection for workers, the public, and the environment” [16]. The LANL TSD has flaws in all three fundamental elements, and thus it does not demonstrate that members of the public or workers are adequately protected during onsite transportation activities.</P>
                    <P>
                        <E T="03">Inadequate Hazard Identification</E>
                        —10 CFR 830, Subpart B, states that the safety basis must “identify and analyze the hazards associated with the work” [3]. The LANL TSD does not contain sufficient analysis for a number of transportation-related hazards.
                    </P>
                    <P>
                        <E T="03">Cliffs Along Transportation Routes</E>
                        —The LANL TSD acknowledges that packages used for onsite transportation may not survive a 30-foot drop and states additional controls are identified to compensate. Many onsite transfers at LANL occur along the Pajarito corridor, a specific section of Pajarito Road on the LANL footprint near facilities such as Area G, the Plutonium Facility, and the Transuranic Waste Facility (TWF). There are steep cliffs along one side of the road, with drops of significantly more than 30 feet in some locations. However, the LANL TSD makes no mention of the specific hazard of the cliffs [17]. During the Board's review of the LANL TSD, Triad personnel identified guardrails and run-off distances along that route and stated that falling down a cliff was not a credible accident scenario. However, neither the guardrails nor the run-off distances are identified, credited, or shown to be sufficient to prevent drops down the cliffs in the LANL TSD. Therefore, the hazard posed by the cliffs along the transfer route is neither identified nor adequately controlled with the specific controls within the LANL TSD.
                    </P>
                    <P>
                        <E T="03">Incompatible Materials</E>
                        —The LANL TSD identifies incompatible materials as a potential hazard in Table 7-1, P&amp;T Hazardous Materials and Associated Design Basis Conditions. However, Table 7-4, Design Basis Conditions and Packaging Performance Envelope for P&amp;T Activities, asserts that the packages meet Type B equivalent level of safety for incompatible materials and thus no additional safety controls are needed. The Type B requirement in 10 CFR 71.43 states there must be assurance that “there will be 
                        <E T="03">no significant chemical, galvanic, or other reaction</E>
                         among the packaging components, 
                        <E T="03">among package contents,</E>
                         or between the packaging components and the package contents” (emphasis added). To meet this requirement, the LANL TSD would need to provide assurance that incompatible materials will not be present in packages, but it currently does not.
                    </P>
                    <P>
                        LANL's 
                        <E T="03">Packaging Evaluation Program</E>
                         document states “the incompatible materials requirements are satisfied through shipper inspection . . . [and] specified in P&amp;T-WI-001” [18]. However, there is no corresponding section of P&amp;T-WI-001 to verify that package contents meet the requirements under 10 CFR 71.43 [19]. Furthermore, the TWF TSRs state that when a container is found that contains oxidizing chemicals or chemical incompatibilities, it is to be removed immediately from TWF, per Limiting Condition of Operation 3.2.3, Condition A, which would rely on onsite transportation to do so [20], thus violating the Type B requirements.
                    </P>
                    <P>Given that there is no inspection of package contents prior to transfer specifically dedicated to ensuring that incompatible materials are not present, and that the TWF TSR requires removal of containers containing incompatible materials, it can be assumed that transfers of incompatible materials may occur. Therefore, the LANL TSD assertion that no additional safety controls need to be developed to account for this hazard is not supported.</P>
                    <P>
                        <E T="03">Pyrophoric Materials</E>
                        —The LANL TSD previously asserted that pyrophoric materials were not applicable. In other words, the hazard of pyrophoric materials did not need to be further analyzed and controlled, because they would never be transported. However, in August 2020, LANL transported pyrophoric material that was not recognized as pyrophoric at the time of transfer. In early March 2021, after titanium metal fines caused sparking in the Plutonium Facility, additional suspect pyrophoric containers were transported from TWF back to the Plutonium Facility (the originator facility). After the fact, Triad completed an analysis that concluded the transported materials were not pyrophoric.
                    </P>
                    <P>
                        The titanium sparking event resulted in a positive unreviewed safety question determination, and in July 2021, NA-LA approved an addendum to the TSD and a revision to the TSRs. The additional packaging control requires “that either a 12-inch POC [pipe overpack container] or a SAVY 4000 container inside a DOT 7A Type A drum be used to transport potentially pyrophoric material” 
                        <SU>8</SU>
                        <FTREF/>
                         [21]. Triad's analysis concluded the packaging configurations would not be “adversely impacted by the oxidation of limited quantities of pyrophoric material” [21]. These containers are also limited to specific quantities of potentially pyrophoric material, per the specific administrative control (SAC) [22].
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             Pipe Overpack Containers (POCs) and SAVY 4000 containers are two types of robust packages used routinely at LANL in various applications.
                        </P>
                    </FTNT>
                    <P>However, the analysis which supports the addendum to the TSD, and the subsequent revision to the TSRs, uses a limited definition of pyrophoric material that only addresses small pieces of special nuclear material metal. This definition would not consider other potentially pyrophoric payloads such as plutonium oxide dispersed within powdered sodium. In this case, since the special nuclear material is not metal pieces, the mixture would not be classified as potentially pyrophoric per the addendum and revised TSRs. Therefore, additional analysis is needed to ensure that all potentially pyrophoric materials are analyzed in the TSD.</P>
                    <P>
                        <E T="03">Inadequate Accident Analysis</E>
                        —10 CFR 830, Subpart B, requires that a DSA must evaluate “normal, abnormal, and accident 
                        <PRTPAGE P="8657"/>
                        conditions,” which will then support the derivation of controls [3]. DOE Standard 1104-2016 expands upon what is necessary to determine that accident analysis is adequate. Namely, the DSA reviewer must be able to reach the conclusion that the “accident analysis methodology is clearly identified and appropriate, including identification of initial conditions and assumptions” and the “accident analysis clearly substantiates the findings of hazard analysis for the design/evaluation basis events and demonstrates the effectiveness of safety class SSCs [structures, systems, and components]” [23].
                    </P>
                    <P>The LANL TSD does not contain any detailed accident analysis. Instead, the TSD develops Table 7-5, Derived Controls for P&amp;T Design Basis Conditions. Within this table, “only drops/impacts, crush, puncture, and fire conditions were considered” because these are the Type B packaging requirements that are not met by the packages used for transfers under this TSD [17]. These are listed in the third column of the table in the TSD. The fourth column contains a brief event description, and the fifth and sixth columns list the preventive and mitigative controls, respectively, for each of these events. An example from the table is provided below.</P>
                    <GPH SPAN="3" DEEP="343">
                        <GID>EN08FE24.034</GID>
                    </GPH>
                    <P>
                        The LANL TSD provides no further description of these accidents; there is no discussion of event frequency, estimated unmitigated or mitigated dose consequences, either qualitative or quantitative, nor any discussion of initial conditions or assumptions. Moreover, the TSD does not discuss how each of the controls listed in the fifth and sixth columns 
                        <E T="03">specifically</E>
                         function in each of the events for which they are credited (as discussed in the 
                        <E T="03">Inadequate Control Set</E>
                         section below). The LANL TSD, with its brief description of events and list of controls, does not constitute formal accident analysis and therefore does not clearly demonstrate alignment with requirements in 10 CFR 830.
                    </P>
                    <P>
                        The NNSA safety basis review team for Revision 3 of the LANL TSD raised a similar concern. NNSA approved Revision 3 of the LANL TSD with various conditions of approval including the condition that “LANL shall develop additional analysis . . . that includes 
                        <E T="03">quantitative estimates of the likelihood</E>
                         of credible scenarios leading to the release of nuclear materials both with and without TSD controls in place, as well as an 
                        <E T="03">estimate of what radiological dose a member of the public</E>
                         located at the most likely site boundary could receive” (emphasis added) [6]. The resulting quantitative analysis was included until Revision 9 of the LANL TSD, which made major changes, including an entire rewrite of the safety assessment section.
                    </P>
                    <P>
                        <E T="03">Inadequate Control Set</E>
                        —10 CFR 830, Subpart B, requires that DSAs “derive the hazard controls necessary to ensure adequate protection of workers, the public, and the environment” and “demonstrate the adequacy of these controls to eliminate, limit, or mitigate identified hazards” [3]. The LANL TSD does not evaluate the effectiveness of hazard controls in relation to each specific accident scenario for which the controls are credited. Rather, the LANL TSD describes generic safety functions for each design feature and SAC, instead of specific safety functions in the context of each accident scenario. Appendix A to 10 CFR 830, Subpart B, states that safety SSCs “require formal definition of minimum acceptable performance in the documented safety analysis” which “is accomplished by first defining a safety function” [3]. DOE Standard 3009-2014 expands on the definition of safety functions: “Safety function descriptions state the objective of the SSC in 
                        <E T="03">a given accident scenario</E>
                        ” (emphasis added) [16].
                    </P>
                    <P>
                        Due to the lack of specific evaluation, the LANL TSD credits controls for accident scenarios where the safety function is unclear or nonexistent. For example, the LANL TSD credits the straps that hold the package to the vehicle (
                        <E T="03">i.e.,</E>
                         tie-down system) as a preventive control in fire scenarios not initiated by package movement, for which the tie-down system appears to provide no preventive 
                        <PRTPAGE P="8658"/>
                        safety function. Further, due to the generic evaluation of controls, the LANL TSD fails to compensate for the absence of the enclosed cargo compartment 
                        <SU>9</SU>
                        <FTREF/>
                         (ECC) design feature and the package design feature in some allowed transfers. For instance, the LANL TSD permits transfer of large packages which would not fit within an ECC. In these cases, the LANL TSD credits a SAC that prohibits all traffic as a replacement for the ECC safety function. However, the SAC does not address numerous accidents where prohibition of traffic would not replace the safety functions of an ECC (
                        <E T="03">e.g.,</E>
                         vehicle drop-off, vehicle impact from other convoy vehicles, fire events from vehicle malfunctions). Additionally, while the TSD limits the quantity of MAR for transfers without an ECC to 1.9 kg plutonium (Pu) 239 equivalent, it provides no quantitative analysis for this lower MAR limit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             An enclosed cargo compartment is “an enclosure with floor, walls on all sides, and a roof in which materials are transferred” [22].
                        </P>
                    </FTNT>
                    <P>The LANL TSD also permits transfers of large objects that “may not fit inside any known package that meets the criteria” in the TSD [24]. In this situation, items such as large pieces of equipment or gloveboxes would be sealed with tape, plastic wrap, or other means, but this sealing method does not provide the same safety function as a package. In some cases these items may also be transported without an ECC. The transfer of large objects then can involve the loss of at least one, if not two, design features, without additional analysis, and therefore the remaining control set for these accident scenarios may not be effective.</P>
                    <P>
                        <E T="03">Significant Public Consequences</E>
                        —As previously discussed, the LANL TSD does not adequately identify all potential hazards, does not adequately analyze accident scenarios, and does not demonstrate the effectiveness of its safety control set. These safety issues are particularly concerning given the high MAR limits, the proximity of transportation routes to the offsite public, and the nature of several credible accident scenarios (
                        <E T="03">e.g.,</E>
                         vehicle fire events). These factors result in the possibility of high unmitigated dose consequences to the offsite public.
                    </P>
                    <P>
                        The July 2007 through March 2012 revisions of the LANL TSD contained quantitative analysis of the risk of LANL onsite transportation activities. These older revisions of the TSD referenced the Area G transuranic (TRU) waste transportation accident and fire scenario from the Area G safety basis dated April 2003. In this accident scenario, a vehicle crashes or rolls over, causing a fire and spilling the waste containers. The postulated MAR in that scenario was the maximum inventory for a truck at the time, which was about 17.7 kg Pu-239 equivalent, and the estimated unmitigated dose consequence to the public was about 190 rem. From November 2012 to June 2023, the LANL TSD allowed up to 20 kg Pu-239 equivalent MAR; therefore, the corresponding estimated dose consequence to the public would have been about 217 rem. The 2003 Area G accident scenario had an estimated likelihood of 10
                        <SU>-3</SU>
                         instances per year (once per thousand years). Additionally, the July 2007 through March 2012 revisions of the LANL TSD noted that the distance to the site boundary for some onsite transportation routes is closer than the distance to the site boundary for Area G; therefore, the July 2007 through March 2012 revisions stated the unmitigated dose consequence for those transportation activities could be substantially higher.
                    </P>
                    <P>The MAR limit within the November 2012 to June 2023 versions of the LANL TSD was based on “an analysis of historical and potential future operations,” with a review of several years of data of onsite transfers, and the “maximum amount of material transferred during this time frame was approximately 18 kg Pu-239 equivalent material” [17], thus the “MAR limit of 20 kg Pu-239 equivalent is bounding for historical operations, and is expected to be bounding for future operations” [22]. However, as stated in DOE Standard 1189-2016, Integration of Safety Into the Design Process, a step in an inherently safe design process is to consider the “removal or reduction of hazards before controls need to be developed,” for example, through “reducing the amount of hazardous material present at any one time” [25]. Rather than basing the MAR limit on historical operations, consideration should be given to reducing MAR to the lowest practicable amount. Other sites' TSDs contain much lower MAR limits than LANL's. For example, LLNL and NNSS both specify a MAR limit of 5 kg Pu-239 equivalent.</P>
                    <P>
                        <E T="03">Current Compensatory Measures</E>
                        —Given the deficiencies in the LANL TSD, it cannot be relied upon to ensure adequate protection of the public or workers during onsite transportation activities. Therefore, until the LANL TSD is revised to address the above safety concerns and/or is revised to comply with an improved safe harbor methodology, compensatory measures are warranted to ensure safety.
                    </P>
                    <P>As discussed previously, on October 11, 2022, NA-LA transmitted a memo to Triad, with an enclosure containing proposed compensatory measures, requesting that Triad develop an impact assessment of the proposed compensatory measures, propose revisions to those measures, and propose additional measures, as applicable, within 60 days. The majority of NA-LA's proposed compensatory measures were related to improvements to existing SACs that would have minor impact on overall safety posture. For instance, NA-LA proposed a compensatory measure to revise the language of the road condition restrictions SAC to include a requirement to check the weather within two hours. While more prescriptive wording in SAC language would be an improvement, this action is already in place per implementing procedures, and therefore this change would have a minor impact. The most impactful proposed compensatory measures from NA-LA were related to MAR limits, packaging, and traffic restrictions. Triad's second response to the NA-LA letter on January 31, 2023, outlined the compensatory measures it planned to implement within 60 days and incorporate in the TSD and TSRs by June 1, 2023. Triad implemented these compensatory measures procedurally on March 31, 2023, and submitted for NA-LA approval a revised TSD and TSRs which incorporated those measures, on June 1, 2023 [10] [11].</P>
                    <P>NA-LA approved the revised TSD and TSRs on August 10, 2023, with two COAs [2]. The first COA directed Triad to resolve NA-LA's comments regarding Type A packaging and the use of functionally equivalent versions of DOT markings. Triad completed this action and submitted the newly revised TSD and TSRs on October 4, 2023 [26]. The second COA directed Triad to resolve additional NA-LA comments on the TSD and TSRs by the 2024 annual update and provide NA-LA with periodic briefings on the status. These additional NA-LA comments covered multiple topics, including hazard identification and control effectiveness, and addressed some of the Board's safety concerns with the LANL TSD.</P>
                    <P>In the case of the compensatory measure of reduced MAR limits, while any reduction in MAR would be an improvement, given the high unmitigated dose consequences, a significant reduction in MAR would be preferable. To this end, Triad's January 31, 2023, letter defined high MAR TRU waste shipments as TRU waste transfers that exceed 1.9 kg Pu-239 equivalent and/or 10 g heat source plutonium. It stated all TRU waste transfers with greater than this quantity of MAR would be conducted using an ECC. Previously, transfers of up to 5 kg Pu-239 equivalent could be conducted without an ECC; therefore, Triad's compensatory measure effectively lowers the MAR limit for non-ECC transfers from 5 to 1.9 kg Pu-239 equivalent. Further, Triad stated that no TRU waste transfers would exceed 8.8 kg Pu-239 equivalent or 80 g heat source plutonium. Previously, the LANL TSD had a limit of 20 kg Pu-239 equivalent for all shipments of radioactive materials. Triad's letter did not articulate compensatory measures for high MAR transfers other than TRU waste, and rather stated Triad would engage with NA-LA to develop transfer-specific controls if there is a need to perform such transfers before an updated TSD is implemented. However, the MAR limits approved in August 2023 do not distinguish between TRU waste and other radioactive materials, apart from the special case of heat source plutonium, and limit transfers of all radioactive materials other than heat source plutonium to 8.8 kg Pu-239 equivalent [10] [11].</P>
                    <P>
                        Further, NA-LA's list of proposed compensatory measures also specified that reductions in MAR be considered in conjunction with packaging. Triad's January 31, 2023, letter stated that heat source plutonium TRU waste shall be transferred in POCs, a relatively robust form of package. While Triad also stated that other plutonium (
                        <E T="03">e.g.,</E>
                         non-heat source) TRU waste packages would meet Type A requirements, this assumption was already part of the TSD package performance envelope. The TSD and TSR approved in August 2023only require POCs for packages that contain greater than 10 g of heat source plutonium [11] [10]. This may allow transfers of up to 80 g of heat source plutonium in non-POCs as long as 
                        <PRTPAGE P="8659"/>
                        each individual package within the shipment contains less than 10 g.
                    </P>
                    <P>
                        Finally, NA-LA's list of proposed compensatory measures included a traffic restriction for certain (
                        <E T="03">e.g.,</E>
                         high MAR) shipments. Triad's January 31, 2023, letter stated that public access would be restricted on transfer routes and that all traffic would be restricted during transfers when an ECC is not used; however, both of these safety controls were previously in place.
                    </P>
                    <P>Overall, the compensatory measures incorporated in the TSD and TSRs approved in August 2023, and the resolution of NA-LA's comments covered by the two COAs, represent an improvement in the safety posture of onsite transportation operations. However, to demonstrate adequate protection of the public and workers at LANL, the hazard analysis, accident analysis, selection of controls, and development of TSRs for onsite transportation need to be reevaluated in accordance with the requirements of 10 CFR 830.</P>
                    <HD SOURCE="HD3">2. Onsite Transportation Directives</HD>
                    <P>The onsite transportation safe harbors do not ensure that TSDs meet 10 CFR 830 requirements or that TSDs contain sufficient analysis and hazard controls for safe operations. Additionally, DOE Standard 1104-2016, Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents, does not contain specific guidance for federal review and approval of TSDs.</P>
                    <P>
                        <E T="03">Noncompliance with 10 CFR 830</E>
                        —The onsite transportation safe harbors lack requirements or guidance for several 10 CFR 830 requirements, most significantly those pertaining to accident evaluation and hazard controls. The table in Attachment C shows an analysis of missing or inadequate requirements and guidance in the onsite transportation safe harbors.
                    </P>
                    <P>On September 13, 2022, DOE responded to the Board's January 2022 letter. DOE asserted that 10 CFR 830 requirements apply “regardless of the methodology for DSA development that is used,” and consequently stated that 10 CFR 830 requirements do not need to flow down into the onsite transportation safe harbors [4]. However, this assertion is inconsistent with the purpose of safe harbors, which is to “provide approved methodologies for meeting the DSA requirements of 10 CFR part 830,” as stated in DOE Standard 1104-2016 [23]. This means that if a contractor follows the safe harbors, then the contractor is assured that all the requirements of 10 CFR 830 will be fulfilled. Given that the onsite transportation safe harbors do not clearly address several 10 CFR 830 requirements, TSDs will not meet the fundamental 10 CFR 830 requirements by solely following the safe harbor methodologies. This is illustrated in the LANL TSD, discussed earlier in this report.</P>
                    <P>This section will discuss the most important 10 CFR 830 requirements that are not covered by DOE Guide 460.1-1, and then will illustrate how other sites' TSDs have supplemented the guide with methodology from DOE Standard 3009-94. Additionally, this section includes discussion of several DOE directives in comparison to the onsite transportation safe harbors. These include DOE Order 461.2, Onsite Packaging and Transfer of Materials of National Security Interest, and DOE Order 461.1C, Packaging and Transportation for Offsite Shipment of Materials of National Security Interest.</P>
                    <P>
                        <E T="03">Evaluation of Accident Scenarios</E>
                        —10 CFR 830 requires evaluation of “normal, abnormal, and accident conditions, including consideration of natural and man-made external events, identification of energy sources or processes that might contribute to the generation or uncontrolled release of radioactive and other hazardous materials” [3]. Systematic evaluation of accident conditions is a necessary component of safety bases to demonstrate adequate protection of the public and workers, as the safety bases are used to determine the need for safety controls. However, the onsite transportation safe harbors do not have requirements or detailed guidance related to the development and evaluation of specific or detailed accident scenarios.
                    </P>
                    <P>DOE Guide 460.1-1 mentions accidents when discussing how TSDs should develop safety controls. It states that TSDs should include “control requirements appropriate for the level of containment and communication provided that take into account the possibility and consequences of credible accidents” [13]. However, the guide does not elaborate on how TSDs should determine the credibility of accidents or consider their risks.</P>
                    <P>
                        Instead of evaluating accidents, there is vague guidance related to the development and evaluation of “design basis conditions” (DBC), which are the conditions that packages should be able to withstand for certain insults (
                        <E T="03">e.g.,</E>
                         fall, fire, penetration).
                        <SU>10</SU>
                        <FTREF/>
                         While determining the conditions that packages can withstand is important, this evaluation is not the same as evaluating accident scenarios. The guide does not discuss identifying initial conditions, assumptions, or specific initiators of various package insults. Further, the guide does not advise that TSDs consider scenarios where multiple package insults could occur (
                        <E T="03">e.g.,</E>
                         a vehicle crash with fire that results in a package both falling down some distance and being exposed to fire).
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             For instance, the guide provides an example of hazardous material that is required to be in a package where the DBC for a fall is 30 feet (
                            <E T="03">i.e.,</E>
                             the package can survive a 30-foot drop). The TSD would then evaluate whether the package can survive a 30-foot drop; otherwise, “additional administrative controls would need to be imposed on the transport system to ensure an adequate level of safety during transport” [13]. The guide further describes how TSDs can include site- and route-specific information in developing and evaluating DBCs. Continuing from the previous example, an evaluation of onsite transportation activities may determine that the greatest fall possible on the transfer route is 10 feet. In this case, if the TSD also imposed a control prohibiting lifting the package above 10 feet during handling, then the DBC would be a fall of 10 feet. From there, the guide includes an expectation that either the package will be shown to survive a 10-foot drop, or additional administrative controls would be needed.
                        </P>
                    </FTNT>
                    <P>Evidence of the lack of requirements and guidance for accident analysis in the safe harbors can be seen in TSDs across the complex. Several sites supplement guidance from the onsite transportation safe harbors with methodologies from DOE Standard 3009-94 for development and analysis of unique, bounding accident scenarios, including quantitative analysis. Examples include the 2011 Hanford TSD, the 2015 Lawrence Livermore National Laboratory (LLNL) TSD, and the 2017 Nevada National Security Site (NNSS) TSD. For instance, the Hanford TSD states that “the accident analysis demonstrates consistency with the guidance in DOE-STD-3009-94” [27]. The LLNL TSD states that DOE-STD-3009-94 was used in “the development of the hazard analysis, accident analysis, selection of controls, and development of” TSRs [28]. The NNSS TSD states that the “analysis process used to evaluate NNSS onsite transportation hazards is patterned after the approach of DOE-STD-3009” [29]. The sites' reliance on methods from another safe harbor to adequately evaluate accident conditions highlights the weakness of the onsite transportation safe harbors.</P>
                    <P>
                        A comparison of the onsite transportation safe harbors to the DOE order for onsite transfers of MNSI further illuminates the weaknesses in the safe harbors. For onsite transfers of MNSI, DOE Order 461.2 states that the “safety assessment must document all credible onsite accident conditions” [30]. Additionally, it states, “[f]or higher hazard (
                        <E T="03">e.g.,</E>
                         hazard category II [
                        <E T="03">sic</E>
                        ]) transfers, it is recommended that a more quantitative analysis be applied (
                        <E T="03">i.e.,</E>
                         DOE-STD-3009). For lower hazard transfers the assessment may be considerably more qualitative” [30]. In contrast, DOE Guide 460.1-1 does not include specific requirements and guidance for accident evaluation, such as that in DOE Standard 3009-2014.
                    </P>
                    <P>
                        Comparing DOE Guide 460.1-1 to DOE Order 461.1C illustrates this issue further. This order establishes the requirements for offsite shipments of MNSI that do not comply with DOT and NRC regulations. Regarding accident analysis, it states, “the DSA must include analysis of the bounding accidents that could occur (
                        <E T="03">i.e.,</E>
                         design basis accidents or DBAs), per the requirements of DOE Standard 3009-2014” [31].
                    </P>
                    <P>
                        <E T="03">Hazard Controls</E>
                        —The onsite transportation safe harbors have no guidance related to the 10 CFR 830 requirement to demonstrate the adequacy of hazard controls “to eliminate, limit, or mitigate identified hazards” [3]. While DOE Guide 460.1-1 states that controls “should ensure that the packaging operates within its established performance envelope,” it provides no guidance or direction on how to evaluate the effectiveness of a control to do so [13]. LLNL and NNSS supplemented their TSDs with guidance from DOE Standard 3009-94 and demonstrated the effectiveness of controls to reduce risk through mitigated hazard and accident analyses. In these analyses, the sites documented the reduction in frequency or consequence caused by applying the safety controls. Further, unlike the onsite transportation safe harbors, both DOE Order 461.1C and DOE Order 461.2 provide additional guidance on the 10 CFR 830 requirement to demonstrate the adequacy of controls for transport of MNSI. DOE Order 461.1C refers to the methodology in DOE 
                        <PRTPAGE P="8660"/>
                        Standard 3009-2014 to meet this requirement. DOE Order 461.2 is less specific but does state that the safety assessment portion of the TSD may select controls and “provide analysis, factoring in the control application” [30].
                    </P>
                    <P>Appendix A to 10 CFR 830, Subpart B also states that developing functional requirements and applicable performance criteria provides assurance that the hazard control will perform its safety function. There is no discussion in DOE Guide 460.1-1 on functional requirements or performance criteria for controls. However, LLNL and NNSS, both of which used DOE Standard 3009-94 to supplement their TSDs, documented specific functional requirements for their credited controls.</P>
                    <P>
                        Finally, 10 CFR 830 requires a safety basis to “define the process for maintaining the hazard controls current at all times and controlling their use” [3]. The onsite transportation safe harbors do not contain guidance for implementing this requirement. DOE Guide 421.1-2A, Implementation Guide for Use in Developing Documented Safety Analyses to Meet Subpart B of 10 CFR 830, states an “expectation associated with any of the safe harbors is that the safety classification guidance for safety SSCs (
                        <E T="03">i.e.,</E>
                         safety class and safety significant SSCs) and specific administrative controls (SACs) of DOE-STD-3009 will be used in developing the DSA” [32].
                    </P>
                    <P>
                        Unlike the onsite transportation safe harbors, DOE Order 461.1C provides several requirements to meet this expectation for transport of MNSI. Due to the proximity to the public for offsite shipments, DOE Order 461.1C requires all such controls to be identified as safety SSCs and requires the application of “the requirements associated with safety-class controls for these `safety SSCs' ” [31]. In comparison, the safe harbors for onsite transportation have no discussion of, or requirements related to, the applicability of other DOE directives' requirements for TSD controls (
                        <E T="03">e.g.,</E>
                         applicability of the design criteria for safety SSCs from DOE Order 420.1C, 
                        <E T="03">Facility Safety</E>
                        ). Additionally, DOE Order 461.1C requires identification of SACs for administrative controls necessary for public safety, worker safety, or defense in depth for transport of MNSI. In comparison, the safe harbors for onsite transportation do not mention SACs, and therefore have no discussion of, or requirements related to, the applicability of requirements contained in DOE Standard 1186-2016, Specific Administrative Controls.
                    </P>
                    <P>
                        <E T="03">Inadequate Evaluation Criteria</E>
                        —An important component of evaluating the level of safety documented in a safety basis is having an objective metric to assess the effectiveness of safety controls at reducing risk. For instance, both the 1994 and 2014 revisions of DOE Standard 3009 apply the concept of an evaluation guideline (25 rem total effective dose for a member of the offsite public), which “the safety analysis evaluates against” and “is established for the purpose of identifying the need for and evaluating safety class controls” [16]. For non-reactor facilities, NRC has criteria similar to DOE Standard 3009, namely for credited controls to reduce the frequency of an event to highly unlikely or its consequence to less severe than 100 rem for the worker and 25 rem for the offsite public. For DOT transportation regulations pertinent to DOE's offsite shipments of radioactive materials, the evaluation criteria apply to the package design itself. For instance, for Type B packages,
                        <SU>11</SU>
                        <FTREF/>
                         10 CFR 71, Subpart E, has a requirement to demonstrate “no loss or dispersal of radioactive contents,” during normal conditions of transport, and to limit radioactive material releases to less than specific amounts during defined hypothetical accident conditions [33].
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             “ `Type A package' means a packaging that, together with its radioactive contents limited to A
                            <E T="52">1</E>
                             or A
                            <E T="52">2</E>
                             as appropriate, meets the requirements of §§ 173.410 and 173.412 and is designed to retain the integrity of containment and shielding required by this part under normal conditions of transport as demonstrated by the tests set forth in § 173.465 or § 173.466, as appropriate.” [39]
                        </P>
                        <P>
                            “ `Type B package' means a packaging designed to transport greater than an A
                            <E T="52">1</E>
                             or A
                            <E T="52">2</E>
                             quantity of radioactive material that, together with its radioactive contents, is designed to retain the integrity of containment and shielding required by this part when subjected to the normal conditions of transport and hypothetical accident test conditions set forth in 10 CFR part 71.” [39]
                        </P>
                        <P>
                            “A
                            <E T="52">1</E>
                             and A
                            <E T="52">2</E>
                             values are given in in § 173.435 or are determined in accordance with § 173.433.” [39]
                        </P>
                    </FTNT>
                    <P>
                        The onsite transportation safe harbors, in contrast, do not provide specific quantitative criteria to evaluate the effectiveness of the safety control set, and thus to understand the risk of onsite transportation operations. Instead, they require that TSDs demonstrate an equivalent level of safety to DOT and NRC regulations for offsite transportation. Specifically, DOE Order 460.1D states that the TSD must “describe the methodology and compliance process to meet equivalent safety for any deviation from 49 CFR parts 171-180 and 49 CFR parts 350-399” [12]. As noted above, DOT and NRC offsite transportation regulations primarily rely on credited packages to provide containment for radioactive materials during pre-defined normal transport and hypothetical accident conditions. DOE Guide 460.1-1 elaborates on this expectation of containment: “For hazardous materials, such as Type B radioactive materials, the transport system would be expected to prevent loss of containment both for normal handling and for all credible onsite accidents” [13]. However, while the guide allows for options other than the use of credited Type B packages (
                        <E T="03">i.e.,</E>
                         it does not mandate the use of Type B packages), it does not describe specifically how to demonstrate an equivalent level of safety for this containment expectation for transportation of packages that cannot survive normal handling or credible onsite accidents (
                        <E T="03">i.e.,</E>
                         non-equivalent packages).
                    </P>
                    <P>In the absence of clear guidance on what constitutes equivalent safety, several sites across the DOE defense nuclear facility complex used quantitative accident analysis to demonstrate that credited controls sufficiently reduced the risk from credible accidents. Sites varied in the thresholds they used; some used 25 rem, and others used 5 rem for the dose to the public. Sites that included a co-located worker analysis used a threshold of either 5 rem or 100 rem. Notably, one site that used the 5 rem threshold stated that this demonstrated equivalent safety to DOT/NRC transportation regulations. The 2017 NNSS TSD states that it achieves equivalent safety by accomplishing several things, including “no release of contents under `credible accident' scenarios,” and if a “release is possible, radiological dose consequences cannot exceed 5 rem to any person in close proximity to the accident within 30 minutes of the incident” [29].</P>
                    <P>
                        Additionally, the DOE order for offsite transportation of MNSI instructs analysts to perform quantitative accident analyses, rather than demonstrating equivalent safety. DOE Order 461.1C states that safety bases “must include analysis of the bounding accidents that could occur (
                        <E T="03">i.e.,</E>
                         design basis accidents or DBAs), per the requirements of DOE Standard 3009-2014” [31]. The requirements of DOE Standard 3009-2014 include using 25 rem as the evaluation guideline for accident analysis. Similarly, the order for onsite transportation of MNSI recommends analysts perform quantitative accident analyses, rather than demonstrating equivalent safety. DOE Order 461.2 states that the TSD “must substantiate the conclusion that a credible accident must not cause individuals to receive a total effective dose (TED) greater than the levels referenced in DOE-STD-1189, Integration of Safety into the Design Process, public protection criteria per Appendix A, section A.2.1” [30]. The cited section defines 25 rem to the public as exceeding the evaluation guideline and 5 rem to the public as challenging the evaluation guideline.
                    </P>
                    <P>
                        The Board communicated the concern with the lack of a clear definition of equivalent safety in its January 6, 2022, letter. In response, DOE acknowledged that improved methodology “to better document analyses of equivalent safety” was warranted and committed to providing better guidance [4]. While this is one method to resolve the concern of inadequate evaluation criteria (
                        <E T="03">i.e.,</E>
                         by better defining equivalent safety), other options exist for providing evaluation criteria, such as using the quantitative methodology provided in DOE Order 461.1C, DOE Order 461.2, and DOE Standard 3009-2014.
                    </P>
                    <P>
                        <E T="03">Methods to Restrict Public Access</E>
                        —The onsite transportation safe harbors do not provide clear guidance on methods to control public access during onsite transfers conducted under TSDs. Multiple correspondences between LANL contractors and DOT have yielded different interpretations of how to restrict public access. This suggests the need for the DOE onsite transportation safe harbors to clearly specify methods for restricting public access.
                    </P>
                    <P>
                        DOE Guide 460.1-1, Attachment 2, is a copy of a 1991 letter from the DOT chief counsel to the director of the Transportation Management Division of DOE. The crux of this letter is defining what constitutes a “public highway” and when transportation of hazardous materials is considered “in commerce.” This is important because “government agencies offering hazardous 
                        <PRTPAGE P="8661"/>
                        materials for transportation in commerce or transporting hazardous materials in furtherance of a commercial enterprise are subject to” the Hazardous Materials Transportation Act, which includes all of the Hazardous Materials Regulations (HMR) [13]. In other words, if a road is considered in commerce, it would not be permissible to conduct onsite transfers of radioactive material in accordance with a TSD; instead, all HMRs would need to be met.
                    </P>
                    <P>A road on government property may still constitute a road in commerce if public access is not controlled. As the 1991 DOT letter states, “[i]f a road is used by members of the general public (including dependents of Government employees) without their having to gain access through a controlled access point, transportation on (across or along) that road is in commerce. On the other hand, if access to a road is controlled at all times through the use of gates and guards, transportation on that road is not in commerce” [13]. The letter provides several examples and specifically states that relying on signs alone to restrict public usage would not be enough to consider the road not in commerce.</P>
                    <P>During the Board's review of the LANL TSD, it became apparent that the guidance contained in the 1991 DOT letter did not provide enough clarity for implementation. The issues raised in the 1991 letter continue to be discussed. For instance, in 2006, a member of the LANL Packaging and Transportation group requested DOT to clarify whether the 1991 letter was still valid “[g]iven the vintage of this correspondence” [34], and the chief of standards development in the DOT Office of Hazardous Materials Standards responded affirmatively [35].</P>
                    <P>
                        Additionally, LANL personnel provided the Board with a letter that the president of Regulatory Resources (a subcontractor located in Los Alamos) sent to DOT in 2018 to request that DOT “confirm the use of signage as a means to achieve public access restriction” [36], and DOT's response [21]. This 2018 letter did not refer to the 1991 DOT letter. DOT responded that “[s]hipments that occur on private roads whose access is restricted to the public (
                        <E T="03">e.g.,</E>
                         limited to authorized personnel), whether by signage (as you described and presented in your letter) or physical barriers, are not subject to the requirements of the HMR” [37]. This response appears to contradict the 1991 letter included in DOE Guide 460.1-1. However, LANL personnel stated that they currently use flaggers to continuously restrict public access to roads during onsite transfers. They further stated that if they decided to apply the guidance in the 2018 letter, they would first declare an Unreviewed Safety Question and obtain DOE approval prior to relying solely on signs to restrict public access.
                    </P>
                    <P>
                        These communications between individual entities and DOT suggest the need for the DOE onsite transportation safe harbors to be more specific regarding the methods necessary to restrict public access. Adequately restricting public access is important from both regulatory and safety perspectives. If public access is not properly restricted, then the public could be closer to onsite transportation activities than analyzed. Therefore, a member of the public could initiate an accident (
                        <E T="03">e.g.,</E>
                         vehicle crash), and could receive a higher radiation dose by being in the vicinity of a transport accident if a release occurred.
                    </P>
                    <P>Additionally, the onsite transportation safe harbors do not provide detailed guidance on controlling onsite traffic of site personnel. Similar to the concern with members of the public, site personnel traveling onsite in government or personal vehicles could initiate an accident during onsite transfers of radioactive material. At LANL in particular, the high operational tempo needed to accomplish its greatly expanded pit manufacturing mission will inevitably increase onsite traffic. Therefore, it is incumbent upon DOE to develop requirements and guidance on the control of site traffic during onsite transfers of radioactive material.</P>
                    <P>
                        <E T="03">DOE Review and Approval of TSDs</E>
                        —DOE Standard 1104-2016, Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents, does not contain guidance for the review and approval of TSDs. The standard mentions transportation only once as an example of other safe harbors allowed by 10 CFR 830 and states that the format of the safety evaluation report (SER) should be based on the safe harbor methodology used. DOE Standard 1104-2016 is divided into topical areas and these “areas and associated criteria established in this Standard form the foundation for reviewing and documenting DSA and TSR approval in an SER” [23]. The lack of guidance related to TSDs is problematic, because field office personnel do not have a set of specific criteria to evaluate whether a TSD ensures safe operations and complies with the onsite transportation safe harbors, as they would have for a DOE Standard 3009-compliant DSA.
                    </P>
                    <P>In response to the Board's January 6, 2022, letter, DOE stated that it would “review DOE-STD-1104 to determine whether improvements are warranted” [4]. The Board concludes that adding criteria specific to TSDs to DOE Standard 1104-2016 is necessary to ensure adequate and consistent reviews by field office personnel across the DOE defense nuclear complex.</P>
                    <HD SOURCE="HD3">3. DOE Oversight</HD>
                    <P>DOE and NNSA failed to identify safety deficiencies in both the DOE directives related to onsite transportation and the LANL TSD. Additionally, DOE and NNSA neglected to ensure that timely corrective actions were taken when the Board identified safety concerns and have struggled to resolve safety concerns when collaboration across program offices is required.</P>
                    <P>
                        <E T="03">DOE Oversight of Directives</E>
                        —DOE issued DOE Guide 460.1-1, the 10 CFR 830 safe harbor methodology for preparing TSDs for onsite transfers of radioactive materials, in 1997 and has not updated it since then. DOE initially issued 10 CFR 830, Subpart B, in 2001, four years after the guide was written. As noted in previous sections, the guide does not contain sufficient guidance to meet several 10 CFR 830 safety basis requirements, which is probably due to being written before 10 CFR 830, Subpart B, was established. As discussed below, DOE did not act on indications of weaknesses with the onsite transportation safe harbors that presented themselves over many years, and its process for revising directives likewise failed to identify these weaknesses.
                    </P>
                    <P>Safety basis personnel at DOE's defense nuclear facilities have at least tacitly recognized the safety deficiencies in DOE Guide 460.1-1 for many years, but DOE has not taken action to improve the guide. For example, many DOE sites supplemented guidance from the onsite transportation safe harbors with methodologies from DOE Standard 3009-94 for development and analysis of unique, bounding accident scenarios, including quantitative analysis. DOE Guide 421.1-2A states that DOE Standard 3009 “is a safe harbor for any of the specialized areas covered by the other safe harbors (with the exception of Hazard Category 1 nuclear reactors) and can be used in lieu of any of them” [32]. While there is no issue with using DOE Standard 3009 methodology when developing TSDs, DOE failed to recognize that its widespread use to supplement the onsite transportation safe harbors' methodology indicated safety deficiencies in the safe harbors. Field offices responsible for reviewing and approving these TSDs could have reached out to the Office of Primary Interest (OPI) for DOE Guide 460.1-1, alerting them to the safety issues with the guide.</P>
                    <P>As another example, DOE revised DOE Order 461.1C in 2016. Previous to this revision, the methodology for developing TSDs for offsite shipments of MNSI was similar to the current DOE Guide 460.1-1. One key change was the addition of an appendix that states that “DOE Standard 3009-2014 . . . is an approved methodology for demonstrating compliance with 10 CFR part 830. DSAs developed by OST [Office of Secure Transport] must comply with the requirements of DOE Standard 3009-2014, except for deviations that are specifically identified in this Appendix” [31]. DOE failed to recognize the corresponding weaknesses in the onsite transportation safe harbors and take action to address them.</P>
                    <P>Additionally, DOE's process for revising directives failed to identify the weaknesses in the onsite transportation safe harbors. DOE's directives review process described in DOE Order 251.1, Departmental Directives Program, assumes the OPI for each directive will review them periodically and propose revisions, as needed, to the Directives Review Board; however, DOE does not require these reviews to be done with a specific periodicity, and OPIs are not required to actively reach out to field elements to solicit feedback. In the case of onsite transportation safety directives, with the DOE Office of Environmental Management designated as the OPI for DOE Guide 460.1-1, this process failed to identify and correct the safety deficiencies in the onsite transportation safe harbors.</P>
                    <P>
                        <E T="03">NNSA Oversight of the LANL TSD</E>
                        —In addition to DOE's failure to correct the safety deficiencies in the transportation directives, NNSA has not resolved safety issues with the LANL TSD specifically. NA-LA and NNSA headquarters packaging and transportation organizations have had multiple 
                        <PRTPAGE P="8662"/>
                        opportunities throughout the years to do so, and yet lasting corrective actions were not taken.
                    </P>
                    <P>The NNSA safety basis review team tasked with review and approval of Revision 3 of the LANL TSD in 2007 consisted of subject matter experts from the Los Alamos Site Office (LASO) (the predecessor organization to NA-LA), the NNSA Service Center, and an independent contractor [6]. Personnel from the NNSA Packaging Certification Division, who were part of the safety basis review team, “concluded that the TSD as submitted did not provide an adequate level of analysis to support the conclusions that for non DOT compliant packages the overall transport system provided an equivalent level of safety” [6]. The associated SER therefore contained several conditions of approval, which included requiring additional analysis supporting the basis for the MAR limit in subsequent TSDs. This additional analysis was to include “quantitative estimates of the likelihood of credible scenarios leading to the release of nuclear materials both with and without TSD controls in place, as well as an estimate of what radiological dose a member of the public located at the most likely site boundary could receive as a result of these release scenarios with the TSD controls in place” [6]. Subsequent revisions of the TSD included such quantitative analysis. However, Revision 9, which became effective in November 2012, contained an entire rewrite of the safety analysis which removed the quantitative analysis. When approving this revision, and each subsequent revision, NA-LA failed to identify the same safety issues that had previously been corrected.</P>
                    <P>Subsequent reviews by NNSA years later failed to detect and correct the same safety issues. NNSA's Office of Packaging and Transportation conducted an assessment of LANL's packaging and transportation program in 2015. While its assessment was primarily focused on MNSI, it also reviewed the LANL TSD. During this review, the team concluded that “LANL has an approved 10 CFR 830 compliant TSD and TSRs that meet 460.1C requirements” [38].</P>
                    <P>Finally, as discussed in DOE's response to the Board's January 6, 2022, letter, on the safety deficiencies in DOE's onsite transportation safety harbors and the LANL TSD, NNSA stated that it “use[s] the Biennial Review process to review field office performance in meeting requirements for the review and approval of TSDs” [4]. However, despite these biennial reviews, NNSA did not identify the safety deficiencies in the LANL TSD.</P>
                    <P>In conclusion, despite multiple instances of NNSA engagement with the LANL TSD, both at the field office level and NNSA headquarters level, NNSA failed to resolve issues with the LANL TSD.</P>
                    <P>
                        <E T="03">DOE Oversight of Identified Safety Issues</E>
                        —Even after the Board expressed safety concerns with the LANL TSD and the onsite transportation safe harbors in its January 6, 2022, letter to the Secretary of Energy, DOE did not take timely action to address these safety concerns.
                    </P>
                    <P>Regarding the LANL TSD, more than a year elapsed between the Board issuing its letter identifying safety deficiencies and Triad issuing its letter informing NA-LA that it would institute compensatory measures for its onsite transportation activities. NA-LA did not begin work on developing proposed compensatory measures through a baseline assessment of TSDs at other NNSA sites until July 2022, six months after the Board sent its letter. NA-LA then transmitted a letter to Triad on October 12, 2022, over 10 months after DOE received the Board's letter, which contained a wide-ranging list of potential compensatory measures for Triad to evaluate. Triad's first response on December 9, 2022, was unsatisfactory. After additional discussions with NA-LA personnel, Triad sent a new letter to NA-LA on January 31, 2023, that agreed to implement a set of compensatory measures that represented an improvement to the safety posture of onsite transportation operations. Nevertheless, this letter did not acknowledge that the compensatory measures were needed to address any safety issues.</P>
                    <P>Further, given the safety concerns identified with the onsite transportation safe harbor, it would have been prudent for DOE to conduct a complete extent of condition review of all sites' TSDs. While DOE's Office of Environmental Management had previously conducted an extent of condition review for a subset of sites under its purview in 2021, it was not formally documented and was done prior to receiving the Board's letter highlighting the specific safety issues.</P>
                    <P>Finally, the Board is concerned with DOE's ability to address safety issues that require collaboration across program offices. DOE's September 13, 2022, letter that responded to the Board's January 6, 2022, letter frankly acknowledged that it would need to evaluate “how we communicate across offices, engage with the field, and share operating experiences across the Department.”</P>
                </EXTRACT>
                <HD SOURCE="HD1">Attachment C—Analysis of Gaps in Onsite Transportation Safe Harbors Related to 10 CFR 830 Requirements</HD>
                <GPOTABLE COLS="4" OPTS="L2,nj,tp0,p7,7/8,i1" CDEF="xs60,r75,r100,r50">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Topical area</CHED>
                        <CHED H="1">
                            10 CFR 830, subpart B
                            <LI>requirement</LI>
                        </CHED>
                        <CHED H="1">DOE order 460.1D and/or DOE guide 460.1-1 reference</CHED>
                        <CHED H="1">Analysis of gaps</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Hazard Identification</ENT>
                        <ENT>830.204(b)(2)—“Provide a systematic identification of both natural and man-made hazards associated with the facility”</ENT>
                        <ENT O="xl">
                            DOE Guide 460.1-1 Section 5.3.1.d. states that the TSD is expected to include “a description of the process and analysis [that] is used to ensure that equivalent safety requirements are established. This should include a technically justified basis for equivalency. For example, this 
                            <E T="03">could</E>
                             include a hazards analysis associated with the transfer.” (emphasis added).
                            <LI O="xl">DOE Guide 460.1-1 Section 5.3.2.c: “This section should identify the physical location of the site and associated facilities on legible maps . . . All features of the site which are mentioned in any part of the document, such as . . . transportation hazards, should be clearly identified on one or more maps.”</LI>
                            <LI O="xl">DOE Guide 460.1-1 Section 5.4.1: “A site seeking to establish a graded approach to compliance with DOE O 460.1A should develop a hierarchy in which hazardous material are grouped into a series of hazard levels.” The Guide then discusses “low hazards”, “higher hazards”, and “hazardous materials, such as Type B radioactive materials.”</LI>
                        </ENT>
                        <ENT>The order does not contain requirements or guidance for this requirement. While the guide discusses identifying transportation hazards on maps and lists hazard analysis as one part of an acceptable way to establish equivalent safety, the guide does not discuss how to systematically identify hazards, including natural and man-made hazards. Further, while the guide discusses developing a hierarchy of hazardous materials, it does not describe how to use this process to identify hazards.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8663"/>
                        <ENT I="01">Hazard Categorization</ENT>
                        <ENT>830.202(b)(3)—“Categorize the facility consistent with DOE-STD-1027-92”</ENT>
                        <ENT>
                            DOE Order 460.1D 4.b.(3)(b): “For onsite transfers involving nuclear facility Hazard Category 2 or 3 quantities, the TSD must comply with the Safety Basis Requirements of 10 CFR 830, Subpart B.”
                            <LI O="xl">DOE Guide 460.1-1 Section 5.1.2: “Such an integrated approach should include hazard classification of the material.”</LI>
                            <LI O="xl">DOE Guide 460.1-1 Section 5.4.1: “A site seeking to establish a graded approach to compliance with DOE O 460.1A should develop a hierarchy in which hazardous material are grouped into a series of hazard levels.” The guide then discusses “low hazards”, “higher hazards”, and “hazardous materials, such as Type B radioactive materials.”</LI>
                        </ENT>
                        <ENT>By requiring that TSDs for transfers of Hazard Category 2 and 3 quantities follow the Safety Basis Requirements in 10 CFR Part 830, Subpart B, the order implicitly requires TSDs to categorize the operations under the hazard categorization scheme of DOE Standard 1027-92. However, the guide does not discuss or invoke the hazard categorization scheme in DOE Standard 1027-92. Instead, the guide allows sites to develop their own hierarchy of hazard classification or levels. The guide frames these levels in terms of low hazards, higher hazards, and hazardous materials such as Type B radioactive materials, which is not the same type of framework as the DOE Standard 1027-92 hazard categorization scheme.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Hazard Controls</ENT>
                        <ENT>830.204(b)(4)—“Derive the hazard controls necessary to ensure adequate protection of workers, the public, and the environment, demonstrate the adequacy of these controls to eliminate, limit, or mitigate identified hazards, and define the process for maintaining the hazard controls current at all times and controlling their use”</ENT>
                        <ENT O="xl">
                            DOE Guide 460.1-1 Section 5.1.2 “Such an integrated approach should include hazard classification of the material, hazard containment, hazard communication, and control measures commensurate with the hazard of the material being transported, 
                            <E T="03">such as</E>
                             . . . control requirements appropriate for the level of containment and communication provided that take into account the possibility and consequences of credible accidents. These control requirements should result in minimal acceptance of risk above the risks accepted in the context of existing Hazardous Materials Regulations” (emphasis added).
                            <LI O="xl">DOE Guide 460.1-1 Section 5.3.1.d. states that the TSD is expected to include “a description of the process and analysis [that] is used to ensure that equivalent safety requirements are established. This should include a technically justifiable basis for equivalency. For example, this could include . . . a discussion of mitigating measures proposed to ensure the equivalent safety requirements will be employed.”</LI>
                            <LI O="xl">DOE Guide 460.1-1 Section 5.4.2 “Before non-equivalent packaging may be used for onsite transport, a performance envelope should be established for the packaging and specific control and communication requirements should be developed which ensure that the transport system will operate safely within the performance envelope.”</LI>
                            <LI O="xl">
                                DOE Guide 460.1-1 Section 5.4.2.c. “controls should be commensurate with the hazard represented by the package being transported, and should ensure that the packaging operates within its established performance envelope. The hazard levels and associated performance requirements documented in Chapter VII of the TSD will greatly facilitate development and justification of appropriate transport controls. Controls may include establishment of special communication requirements (
                                <E T="03">e.g.,</E>
                                 radio contact with emergency response personnel) which are required to compensate for packaging inadequacies.”
                            </LI>
                        </ENT>
                        <ENT>
                            While the guide indicates that hazard controls should be developed as needed, it does not present or require a method to determine adequacy of these controls to eliminate, limit, or mitigate hazards.
                            <LI>The guide does not define a process for maintaining the hazard controls or controlling their use.</LI>
                            <LI>The guide states that TSDs should establish control requirements that will result in “minimal acceptance of risk above those accepted in the context of existing Hazardous Materials Regulations.” However, the guide does not include a clear and consistent definition of what equivalency to these regulations entails.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8664"/>
                        <ENT I="01">Evaluation of Accident Conditions</ENT>
                        <ENT>830.204(b)(3)—“Evaluate normal, abnormal, and accident conditions, including consideration of natural and man-made external events, identification of energy sources or processes that might contribute to the generation or uncontrolled release of radioactive and other hazardous materials, and consideration of the need for analysis of accidents which may be beyond the design basis of the facility”</ENT>
                        <ENT>
                            DOE Guide 460.1-1 Section 5.1.2 “Such an integrated approach 
                            <E T="03">should</E>
                             include hazard classification of the material, hazard containment, hazard communication, and control measures commensurate with the hazard of the material being transported, 
                            <E T="03">such as</E>
                             . . . control requirements appropriate for the level of containment and communication provided 
                            <E T="03">that take into account the possibility and consequences of credible accidents</E>
                            ” (emphasis added)
                            <LI O="xl">DOE Guide 460.1-1 Section 5.4.2.b. “To establish the performance envelope of the packaging, evaluation of design basis conditions (DBCs) is recommended. DBCs should be site-specific and possibly route-specific conditions under which the packaging should be able to provide containment during onsite transport. DBCs to be considered for a particular hazardous materials transport will depend on the hazard level of the material.”</LI>
                            <LI O="xl">“Chapter VII of the TSD should include guidance on which DBCs should be developed for each hazard level, and should establish minimum performance requirements for each hazard level. Examples of DBCs which may be appropriate for some hazard levels are shock, vibration, collision, fall, fire, penetration, and immersion. Others may also be appropriate.”</LI>
                            <LI O="xl">“To illustrate how the performance requirements established in Chapter VII of the TSD can be used to develop an appropriate DBC, a particular hazardous material may be grouped into a hazard level that requires a packaging to be able to survive a 3-ft drop with no loss of containment. For this hazardous material, a 3-ft drop would then become the DBC for falls, without regard to conditions along the transport route or during handling which might expose the packaging to a fall from a higher distance. If the packaging could not survive a 3-ft drop, additional administrative controls would need to be imposed on the transport system to ensure an adequate level of safety during transport. Guidance regarding appropriate administrative controls should be provided in Chapter VII of the TSD.”</LI>
                        </ENT>
                        <ENT>
                            The order does not contain requirements or guidance for this requirement.
                            <LI>The guide discusses including control requirements that consider the frequency and consequence of credible accidents, but does not require such evaluation of accidents. Further, the guide does not describe what type of accidents must or should be included.</LI>
                            <LI>The guide also discusses analyzing transport conditions and ensuring that packages are not exposed to conditions they cannot survive, such as a large drop-off. While this could constitute an analysis of transportation conditions, such analysis does not necessarily evaluate the initiators, frequency, or consequences of accident conditions.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT O="xl">“As an example of how physical limitations of a site may be incorporated into a DBC, a particular hazardous material may be grouped into a hazard level that requires a packaging to be able to survive a 30-ft drop. For this particular hazardous material shipment, an evaluation of the transport route may show that, for any accident which could occur along the transport route, the packaging could never fall more than 10 ft. If a control on the packaging is also imposed requiring that the packaging never be elevated more than 10 ft during handling, the DBC need only consider a 10-ft fall.”</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Technical Safety Requirements</ENT>
                        <ENT>
                            830.205(a)(1)—“Develop technical safety requirements that are derived from the documented safety analysis”
                            <LI>830.205(a)(2)—“Prior to use, obtain DOE approval of technical safety requirements and any change to technical safety requirements”</LI>
                        </ENT>
                        <ENT>No requirement or guidance in the order or guide. Neither document mentions technical safety requirements</ENT>
                        <ENT>
                            The order and the guide lack requirements and guidance regarding technical safety requirements. While DOE has other directives related to technical safety requirements (
                            <E T="03">e.g.,</E>
                             DOE Guide 423.1-1B, Implementation Guide for Use in Developing Technical Safety Requirements), the safe harbors do not reference those other relevant DOE directives.
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">References</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">[1] Triad National Security, LLC, Submittal of PT-SA-002-R15, P&amp;T Transportation Safety Document, and PT-TSR-001-R13, Technical Safety Requirements, NSP-23-042, 2023.</FP>
                    <FP SOURCE="FP-2">[2] Los Alamos Field Office, Approval of Submittal of PT-SA-002-R15 Packaging and Transportation Safety Document and PT-TSR-001-R13 Technical Safety Requirements, NNSA-2023-004544, August 10, 2023.</FP>
                    <FP SOURCE="FP-2">[3] Title 10 Code of Federal Regulations, Part 830, Nuclear Safety Management.</FP>
                    <FP SOURCE="FP-2">[4] J. Hruby, Department letter responding to the Board letter of January 6, 2022, regarding the adequacy of the LANL onsite transportation safety document and the onsite transportation safe harbors, September 13, 2022.</FP>
                    <FP SOURCE="FP-2">[5] Department of Energy, Preparation Guide for U.S. Department of Energy Nonreactor Nuclear Facility Documented Safety Analyses, DOE Standard 3009-94 Change Notice 3, 1994.</FP>
                    <FP SOURCE="FP-2">[6] Los Alamos Site Office, Transmittal of Safety Evaluation Report Approving Annual Update of Transportation Safety Document (TSD) and Technical Safety Requirements (TSRs), March 22, 2007.</FP>
                    <FP SOURCE="FP-2">[7] Department of Energy, Department of Energy Nuclear Safety Policy, DOE P 420.1, 2011.</FP>
                    <FP SOURCE="FP-2">[8] Los Alamos National Laboratory, Transportation Safety Document, P&amp;T-SA-002, R8.1, 2012.</FP>
                    <FP SOURCE="FP-2">[9] Los Alamos National Laboratory, TA-54 Area G Documented Safety Analysis, ABD-WFM-001, R.0, April 2003.</FP>
                    <FP SOURCE="FP-2">[10] Triad National Security, LLC, Packaging and Transportation Transportation Safety Document, P&amp;T-SA-002-R15, 2023.</FP>
                    <FP SOURCE="FP-2">[11] Triad National Security, LLC, Packaging and Transportation Technical Safety Requirements, PT-TSR-001-R13, 2023.</FP>
                    <FP SOURCE="FP-2">
                        [12] Department of Energy, Hazardous 
                        <PRTPAGE P="8665"/>
                        Materials Packaging and Transportation Safety, DOE Order 460.1D Chg 1, June 2022.
                    </FP>
                    <FP SOURCE="FP-2">[13] Department of Energy, Implementation Guide for Use with DOE O 460.1A, Packaging and Transportation Safety, DOE G 460.1-1, June 1997.</FP>
                    <FP SOURCE="FP-2">[14] Triad National Security, LLC, P&amp;T Transportation Safety Document Impact Assessment, NSP-22-094, December 9, 2022.</FP>
                    <FP SOURCE="FP-2">[15] Triad National Security, LLC, P&amp;T Transportation Safety Document Compensatory Measures, January 31, 2023.</FP>
                    <FP SOURCE="FP-2">[16] Department of Energy, Preparation of Nonreactor Nuclear Facility Documented Safety Analysis, DOE-STD-3009-2014, November 2014.</FP>
                    <FP SOURCE="FP-2">[17] Triad National Security, LLC, Transportation Safety Document (TSD), P&amp;T-SA-002, R12, April 2017.</FP>
                    <FP SOURCE="FP-2">[18] Triad National Security, LLC, Packaging Evaluation Program, P&amp;T-PLAN-018, R12, May 7, 2020.</FP>
                    <FP SOURCE="FP-2">[19] Triad National Security, LLC, Transportation Safety Document Authorized Shipper/Transfer Evaluator Instructions, P&amp;T-WI-001, R19, July 24, 2020.</FP>
                    <FP SOURCE="FP-2">[20] Triad National Security, LLC, Technical Safety Requirements for Transuranic Waste Facility (TWF), TSR-TWF-002, Rev 2.4, April 2020.</FP>
                    <FP SOURCE="FP-2">[21] Los Alamos Field Office, Approval of P&amp;T-SA-002-R12 Addendum 3-R0, Analysis of Transport of Pyrophoric Material, and P&amp;T-TSR-001-R10-.1, Technical Safety Requirements, NNSA-2021-002752, July 2021.</FP>
                    <FP SOURCE="FP-2">[22] Triad National Security, LLC, Packaging and Transportation Technical Safety Requirements, P&amp;T-TSR-001-R10.1, May 17, 2021.</FP>
                    <FP SOURCE="FP-2">[23] Department of Energy, Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents, DOE-STD-1104-2016, December 2016.</FP>
                    <FP SOURCE="FP-2">[24] Los Alamos National Laboratory, Packaging Evaluation Program, P&amp;T-PLAN-018, R12, May 2020.</FP>
                    <FP SOURCE="FP-2">[25] Department of Energy, Integration of Safety into the Design Process, DOE-STD-1189-2016, December 2016.</FP>
                    <FP SOURCE="FP-2">[26] Triad National Security, LLC, Submittal of P&amp;T-SA-002-R16, P&amp;T Transportation Safety Document and PT-TSR-001-R14, Technical Safety Requirements, NSP-23-091, October 4, 2023.</FP>
                    <FP SOURCE="FP-2">[27] Hanford Site, Hanford Sitewide Transportation Safety Document, DOE/RL-2001-36, Revision 1-E, May 2011.</FP>
                    <FP SOURCE="FP-2">[28] Lawrence Livermore National Laboratory, Lawrence Livermore National Laboratory Transportation Safety Document, UCRL-MA-152462-REV-5, December 2015.</FP>
                    <FP SOURCE="FP-2">[29] National Security Technologies, LLC, Nuclear Onsite Transportation Safety Document for the Nevada National Security Site, OTSD-NSAF.100, Rev. 3, June 2017.</FP>
                    <FP SOURCE="FP-2">[30] Department of Energy, Onsite Packaging and Transfer of Materials of National Security Interest, DOE O 461.2, November 2010.</FP>
                    <FP SOURCE="FP-2">[31] Department of Energy, Packaging and Transportation for Offsite Shipment of Materials of National Security Interest, DOE O 461.1C, December 2019.</FP>
                    <FP SOURCE="FP-2">[32] Department of Energy, Implementation Guide for Use in Developing Documented Safety Analyses to Meet Subpart B of 10 CFR 830, DOE G 421.1-2A, December 2011.</FP>
                    <FP SOURCE="FP-2">[33] Title 10 Code of Federal Regulations, Part 71, Subpart E, Package Approval Standards.</FP>
                    <FP SOURCE="FP-2">[34] J. Lowery, Letter to Director of Office of Hazardous Materials Standards at U.S. Department of Transportation, Los Alamos: Los Alamos National Laboratory Packaging and Transportation, May 17, 2006.</FP>
                    <FP SOURCE="FP-2">[35] J. A. Gale, Response Letter to Joseph Lowery, Ref. No. 06-0135, Washington: Standards Development, Office of Hazardous Materials Standards, U.S. Department of Transportation, July 11, 2006.</FP>
                    <FP SOURCE="FP-2">[36] W. Winters, Letter to Standards and Rulemaking Division, Pipeline and Hazardous Materials Safety Administration of the U.S. Department of Transportation, Los Alamos: Regulatory Resources Inc., November 29, 2018.</FP>
                    <FP SOURCE="FP-2">[37] D. Der Kinderen, Response Letter to Letter from Wade Winters President of Regulatory Resources Inc., Reference No. 18-0152, Washington: Standards Development Branch, Standards and Rulemaking Division, U.S. Department of Transportation, April 16, 2019.</FP>
                    <FP SOURCE="FP-2">[38] NNSA Office of Packaging and Transportation, Assessment Report for DOE Orders 461.1B, 461.2 and 460.1C Compliance Review at Los Alamos National Laboratory, March 2016.</FP>
                    <FP SOURCE="FP-2">[39] Title 49 Code of Federal Regulations Part 173, Shippers—General Requirements for Shipments and Packages.</FP>
                </EXTRACT>
                <HD SOURCE="HD1">Correspondence With the Secretary of Energy</HD>
                <EXTRACT>
                    <HD SOURCE="HD2">Department of Energy Request for Extension of Time</HD>
                    <FP>September 15, 2023</FP>
                    <FP>The Honorable Joyce L. Connery Chair</FP>
                    <FP>Defense Nuclear Facilities Safety Board, 625 Indiana NW, Suite 700</FP>
                    <FP>Washington, DC 20004</FP>
                    <FP>Dear Chair Connery:</FP>
                    <P>
                        The Department of Energy (DOE) received the Defense Nuclear Facilities Safety Board (DNFSB) draft Recommendation 2023-1, 
                        <E T="03">Onsite Transportation Safety,</E>
                         on August 3, 2023. The draft Recommendation spans multiple DOE program, staff, and site offices, and DOE is currently coordinating our review among the relevant offices.
                    </P>
                    <P>In accordance with 42 U.S.C. 2286d(a)(2), the Department requests a 60-day extension through November 2, 2023, to provide comments. This extension will afford DOE sufficient time to assess the findings, supporting data, and analyses of the draft Recommendation.</P>
                    <P>If you have any questions, please contact Mr. Ahmad M. Al-Daouk, National Nuclear Security Administration Associate Administrator for Environment, Safety, and Health, at (505) 845-4607.</P>
                    <FP>Sincerely,</FP>
                    <FP>Jennifer Granholm</FP>
                    <HD SOURCE="HD2">Defense Nuclear Facilities Safety Board Response to Extension Request</HD>
                    <FP>September 19, 2023</FP>
                    <FP>The Honorable Jennifer Granholm Secretary of Energy</FP>
                    <FP>U.S. Department of Energy</FP>
                    <FP>1000 Independence Avenue SW, Washington, DC 20585-1000</FP>
                    <FP>Dear Secretary Granholm:</FP>
                    <P>The Defense Nuclear Facilities Safety Board (Board) has received the Department of Energy's September 15, 2023, letter requesting an extension until November 2, 2023, to provide comments regarding the Board's draft Recommendation 2023-1, Onsite Transportation Safety. In accordance with 42 U.S.C. 2286d(a)(2), the Board grants this request.</P>
                    <P>Please note that the Atomic Energy Act allows the Board to issue a final recommendation after the expiration of a 30-day period for the Secretary to provide comments on a draft recommendation. 42 U.S.C. 2286d(a)(3). In this instance, the 30-day period expired on September 2, 2023. The Board respectfully requests that, in the future, if the Department wishes to seek an extension of the 30-day period, it do so before that period elapses, so that the Board receives and can consider extension requests in a timely manner.</P>
                    <FP>Sincerely,</FP>
                    <FP>Joyce L. Connery Chair</FP>
                    <HD SOURCE="HD2">Department of Energy Comments on Draft Recommendation</HD>
                    <FP>November 1, 2023</FP>
                    <FP>The Honorable Joyce L. Connery</FP>
                    <FP>Chair, Defense Nuclear Facilities Safety Board, 625 Indiana NW, Suite 700</FP>
                    <FP>Washington, DC 20004</FP>
                    <FP>Dear Chair Connery:</FP>
                    <P>
                        The Department of Energy (DOE) received the Defense Nuclear Facilities Safety Board (DNFSB/Board) Draft Recommendation 2023-1, 
                        <E T="03">Onsite Transportation Safety,</E>
                         dated August 3, 2023. This letter discusses DOE's recent efforts for improving onsite transportation safety at Los Alamos National Laboratory (LANL) and provides comments on Draft Recommendation 2023-1.
                    </P>
                    <P>
                        As captured in DOE's September 2022 response 
                        <SU>12</SU>
                        <FTREF/>
                         to the Board's January 2022 letter,
                        <SU>13</SU>
                        <FTREF/>
                         the Department has already agreed to take actions to address some of the items in Draft Recommendation 2023-1. The National Nuclear Security Administration (NNSA) previously agreed to identify near-term improvements to the LANL Transportation Safety Document (TSD) controls, and on 
                        <PRTPAGE P="8666"/>
                        August 10, 2023, the Los Alamos Field Office approved an update to the LANL TSD and Technical Safety Requirements (TSRs). The approved LANL TSD and TSRs elevate the compensatory measures to TSRs as discussed in Draft Recommendation 2023-1 and directs LANL to address, as conditions of approval, NNSA comments that are consistent with the concerns raised by the Board in your observations and previous letters. NNSA will ensure the Los Alamos Field Office and LANL address the remaining conditions of approval in the TSD and TSRs by the next annual update in August 2024. Correcting these issues will strengthen onsite transportation safety at Los Alamos until the regulatory framework is updated.
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             DOE letter and report to Joyce Connery, Board Chair, responding to DNFSB January 6, 2022, letter regarding onsite transportation safety at DOE defense nuclear facilities, dated September 13, 2022.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             Letter to Jennifer Granholm, Secretary of Energy, from Joyce Connery, Board Chair, dated January 6, 2022, requesting a report and briefing regarding onsite transportation safety at DOE defense nuclear facilities.
                        </P>
                    </FTNT>
                    <P>
                        In the report attached to DOE's September 2022 letter, DOE stated that it “plans to review the requirements of 10 CFR part 830, subpart B, and will determine whether an improved methodology and/or guidance for performing 10 CFR part 830, subpart B-compliant [documented safety analysis] and TSR development for onsite transportation at DOE defense nuclear facilities is warranted.” DOE also agreed to “update the discussion in DOE Standard (STD) 1104-2016, 
                        <E T="03">Review and Approval of Nuclear Facility Safety Basis and Safety Design Basis Documents,</E>
                         to clarify the expectations for DOE to review and approve TSDs.”
                    </P>
                    <P>The Department previously agreed to improving interfaces for how we communicate, engage, and share expertise with the field after the near-term and long-term actions for onsite transportation safety are completed, and we intend to share operating experiences across the defense nuclear facility complex.</P>
                    <P>DOE has the following two comments on Draft Sub-Recommendations 2.c and Draft Recommendation 3:</P>
                    <P>1. In Draft Sub-Recommendation 2.c, the Board recommends DOE “[c]onduct an extent of condition review of TSDs for DOE sites with defense nuclear facilities to identify any near-term actions necessary to ensure safety until the safe harbors are revised and implemented.” As identified in the Draft Recommendation, the DOE Office of Environmental Management conducted an extent of condition assessment in 2021. Therefore, DOE suggests the Board change Sub-Recommendation 2.c to limit the extent of condition review to NNSA sites. NNSA would commit to complete these reviews in a timely manner.</P>
                    <P>2. DOE believes that Departmental resources for ensuring safety of onsite transportation activities are best used to support the actions encompassed in Draft Recommendations 1 and 2. Sub-Recommendation 3a appears to recommend analysis and review that will be an essential part of the approach to developing improved safe harbor(s) required as part of Recommendation 2. Sub-Recommendation 3b appears to require a second parallel process that would replicate corrective action activities that will be required for Recommendation 1. DOE suggests removing Draft Recommendation 3, or at least Sub- Recommendation 3b.</P>
                    <P>Thank you for providing Draft Recommendation 2023-1 for our review. We appreciate the Board's insights and advice on this important topic. DOE remains committed to sharing information with the Board and offers to brief the Board or DNFSB staff on the status of these issues as we progress. With the consideration of the comments above, DOE believes that these actions adequately address the Board's concerns. If you have any questions, please contact Mr. Ahmad M. Al-Daouk, NNSA Associate Administrator for Environment, Safety, and Health, at (505) 845-4607.</P>
                    <FP>Sincerely,</FP>
                    <FP>Jennifer Granholm</FP>
                </EXTRACT>
                <P>
                    <E T="03">Authority:</E>
                     42 U.S.C. 2286d(b)(2).
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Joyce Connery,</NAME>
                    <TITLE>Chair.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02513 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3670-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF EDUCATION</AGENCY>
                <SUBJECT>President's Board of Advisors on Historically Black Colleges and Universities</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>President's Board of Advisors on Historically Black Colleges and Universities, Office of the Secretary, U.S. Department of Education.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Announcement of an open meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice sets forth the agenda for the winter 2024 meeting of the President's Board of Advisors on Historically Black Colleges and Universities (Board) and provides information to members of the public about how to attend the meeting, request to make oral comments at the meeting, and submit written comments pertaining to the work of the Board.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>On February 29, 2024, the Board will hold a virtual meeting from 11 a.m. to 3:30 p.m. E.D.T.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sedika Franklin, Associate Director/Designated Federal Official, U.S. Department of Education, White House Initiative on Historically Black Colleges and Universities, 400 Maryland Avenue SW, Washington, DC 20202, (202) 453-5630 or by email at 
                        <E T="03">sedika.franklin@ed.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Board's Statutory Authority and Function: The Board is established by 20 U.S.C. 1063e (the HBCUs Partners Act) and Executive Order 14041 (September 3, 2021) and is continued by Executive Order 14109 (September 29, 2023). The Board is also governed by the provisions of 5 U.S.C. chapter 10 (Federal Advisory Committees), which sets forth standards for the formation and use of advisory committees. The purpose of the Board is to advise the President, through the White House Initiative on Historically Black Colleges and Universities (Initiative), on all matters pertaining to strengthening the educational capacity of Historically Black Colleges and Universities (HBCUs).</P>
                <P>The Board shall advise the President in the following areas: (i) improving the identity, visibility, and distinctive capabilities and overall competitiveness of HBCUs; (ii) engaging the philanthropic, business, government, military, homeland-security, and education communities in a national dialogue regarding new HBCU programs and initiatives; (iii) improving the ability of HBCUs to remain fiscally secure institutions that can assist the Nation in achieving its educational goals and in advancing the interests of all Americans; (iv) elevating the public awareness of, and fostering appreciation of, HBCUs; (v) encouraging public-private investments in HBCUs; and (vi) improving government-wide strategic planning related to HBCU competitiveness to align Federal resources and provide the context for decisions about HBCU partnerships, investments, performance goals, priorities, human capital development, and budget planning.</P>
                <P>
                    <E T="03">Meeting Agenda:</E>
                     The meeting agenda will include roll call; approval of the minutes from the June 21, 2023 Board meeting); an update from the Board Chairperson; an update from U.S. Department of Education staff; an update from the Executive Director of the Initiative; a status report from each of the Board's subcommittees (Preservation and Growth, Infrastructure, and Career Pathways and Financial Support and Research); and a discussion regarding the status of the Board's report to the President. The public comment period will begin immediately following the conclusion of such discussions. The Board will hold a vote on recommendations presented by its subcommittees and/or any final elements of its report to the President.
                </P>
                <P>
                    <E T="03">Access to the Meeting:</E>
                     An advance RSVP is not required to attend the meeting. The public may join the meeting at the following link: 
                    <E T="03">https://events.intellor.com/login/507127</E>
                    . Members of the public who cannot join by computer may dial in by phone at 1-202-735-3323 with access code 7485504#.
                </P>
                <P>
                    To join the meeting, please click on the appropriate link, enter your name, email address, and organization, and follow the prompts to connect to the meeting audio by computer or 
                    <PRTPAGE P="8667"/>
                    telephone. Members of the public may virtually join the meeting 10 minutes prior to their start time. Members of the public joining by phone will be automatically placed in listen only mode.
                </P>
                <P>
                    <E T="03">Submission of requests to make an oral comment:</E>
                     There will be an allotted time for oral comment at all meetings. The public may submit a request to make oral comment by sending a note via the chat function to the Host and Presenters of each meeting. Please include “Oral Comment Request” in the note and provide the name, title, organization/affiliation, and email address of the person requesting to speak. Those joining by phone will be given instructions by the event producer on how to make oral comment. The Designated Federal Official will call upon each requestor in the order in which the requests were received. Each individual who makes a request will have an opportunity to speak for up to two minutes. All oral comments will become part of the official record of the meeting.
                </P>
                <P>
                    <E T="03">Submission of written comments:</E>
                     Written comments must be submitted to the 
                    <E T="03">whirsvps@ed.gov</E>
                     mailbox no later than two business days before each meeting. Please include in the subject line “Written Comments: Public Comment.” The email must include the name(s), title, organization/affiliation, mailing address, email address, and telephone number of the person(s) making the comment. Comments should be submitted as a Microsoft Word document or in a medium compatible with Microsoft Word (not a PDF file) that is attached to the email or provided in the body of the email message. Please do not send material directly to the members of the Board. Written comments will become part of the official record of the meeting.
                </P>
                <P>
                    <E T="03">Access to Records of the Meeting:</E>
                     The Department will post the official report of the meeting on the Board's website, 
                    <E T="03">https://sites.ed.gov/whhbcu/policy/presidents-board-of-advisors-pba-on-hbcus,</E>
                     no later than 90 days after the meeting. Pursuant to 5 U.S.C. 1009(b), the public may also inspect the meeting materials and other Board records at 400 Maryland Avenue SW, Washington, DC, by emailing 
                    <E T="03">oswhi-hbcu@ed.gov</E>
                     or by calling (202) 453-5634 to schedule an appointment.
                </P>
                <P>
                    <E T="03">Reasonable Accommodations:</E>
                     The meeting site is accessible to individuals with disabilities. If you will need an auxiliary aid or service to participate in the meeting (
                    <E T="03">e.g.,</E>
                     interpreting service, assistive listening device, or materials in an alternate format), notify the contact person listed in this notice at least two weeks before the meeting date. Although we will attempt to meet a request received after that date, we may not be able to make available the requested auxiliary aid or service because of insufficient time to arrange it.
                </P>
                <P>
                    <E T="03">Electronic Access to this Document:</E>
                     The official version of this document is the document published in the 
                    <E T="04">Federal Register</E>
                    . Free internet access to the official edition of the 
                    <E T="04">Federal Register</E>
                     and the Code of Federal Regulations is available via the Federal Digital System at: 
                    <E T="03">www.gpo.gov/fdsys</E>
                    . At this site you can view this document, as well as all other documents of this Department published in the 
                    <E T="04">Federal Register</E>
                    , in text or Adobe Portable Document Format (PDF). To use PDF, you must have Adobe Acrobat Reader, which is available free at the site.
                </P>
                <P>
                    You may also access documents of the Department published in the 
                    <E T="04">Federal Register</E>
                     by using the article search feature at: 
                    <E T="03">www.federalregister.gov</E>
                    . Specifically, through the advanced search feature at this site, you can limit your search to documents published by the Department.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     HBCUs Partners Act, Presidential Executive Order 14041, continued by Executive Order 14109. Notice of the meeting is required by 5 U.S.C. chapter 10 (Federal Advisory Committees) and is intended to notify the public of an opportunity to attend the meeting.
                </P>
                <SIG>
                    <NAME>Alexis Barrett,</NAME>
                    <TITLE>Chief of Staff, Office of the Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02524 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <DEPDOC>[Docket No. ER24-1163-000]</DEPDOC>
                <SUBJECT>CPV Backbone Solar, LLC; Supplemental Notice That Initial Market-Based Rate Filing Includes Request for Blanket Section 204 Authorization</SUBJECT>
                <P>This is a supplemental notice in the above-referenced proceeding of CPV Backbone Solar, LLC's application for market-based rate authority, with an accompanying rate tariff, noting that such application includes a request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability.</P>
                <P>Any person desiring to intervene or to protest should file with the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, in accordance with Rules 211 and 214 of the Commission's Rules of Practice and Procedure (18 CFR 385.211 and 385.214). Anyone filing a motion to intervene or protest must serve a copy of that document on the Applicant.</P>
                <P>Notice is hereby given that the deadline for filing protests with regard to the applicant's request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability, is February 22, 2024.</P>
                <P>
                    The Commission encourages electronic submission of protests and interventions in lieu of paper, using the FERC Online links at 
                    <E T="03">http://www.ferc.gov</E>
                    . To facilitate electronic service, persons with internet access who will eFile a document and/or be listed as a contact for an intervenor must create and validate an eRegistration account using the eRegistration link. Select the eFiling link to log on and submit the intervention or protests.
                </P>
                <P>Persons unable to file electronically may mail similar pleadings to the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426. Hand delivered submissions in docketed proceedings should be delivered to Health and Human Services, 12225 Wilkins Avenue, Rockville, Maryland 20852.</P>
                <P>
                    In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (
                    <E T="03">http://www.ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact the Federal Energy Regulatory Commission at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TYY, (202) 502-8659.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as 
                    <PRTPAGE P="8668"/>
                    interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov</E>
                    .
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02604 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <DEPDOC>[Project No. 2411-030]</DEPDOC>
                <SUBJECT>Eagle Creek Schoolfield Hydro, LLC, City of Danville; Notice of Application Accepted for Filing and Soliciting Motions To Intervene and Protests</SUBJECT>
                <P>Take notice that the following hydroelectric application has been filed with the Commission and is available for public inspection.</P>
                <P>
                    a. 
                    <E T="03">Type of Application:</E>
                     New Major License.
                </P>
                <P>
                    b. 
                    <E T="03">Project No.:</E>
                     2411-030.
                </P>
                <P>
                    c. 
                    <E T="03">Date filed:</E>
                     July 29, 2022.
                </P>
                <P>
                    d. 
                    <E T="03">Applicant:</E>
                     Eagle Creek Schoolfield, LLC and City of Danville.
                </P>
                <P>
                    e. 
                    <E T="03">Name of Project:</E>
                     Schoolfield Hydroelectric Project (Schoolfield Project or project).
                </P>
                <P>
                    f. 
                    <E T="03">Location:</E>
                     On the Dan River at approximately river mile 60.1 in the county of Pittsylvania, near the City of Danville, Virginia.
                </P>
                <P>
                    g. 
                    <E T="03">Filed Pursuant to:</E>
                     Federal Power Act 16 U.S.C. 791(a)-825(r).
                </P>
                <P>
                    h. 
                    <E T="03">Applicant Contact:</E>
                     Jody Smet, Vice President, Engineering and Regulatory Affairs, Eagle Creek Renewable Energy, LLC, 7315 Wisconsin Ave., Suite 1100W, Bethesda, Maryland 20814; phone at (804) 382-1764 or email at 
                    <E T="03">jody.smet@eaglecreekre.com</E>
                    ; Joyce Foster, Director, Licensing and Compliance, Eagle Creek Renewable Energy, LLC, 7315 Wisconsin Avenue, Suite 1100W, Bethesda, Maryland 20814; phone at (804) 338-5110 or email at 
                    <E T="03">Joyce.Foster@eaglecreekre.com</E>
                    ; and Mr. W. Clarke Whitfield, Junior, City Attorney, City of Danville, 427 Patton Street, Room 421, Danville, Virginia 24541; phone at (434) 799-5122 or email at 
                    <E T="03">whitfcc@danvilleva.gov</E>
                    .
                </P>
                <P>
                    i. 
                    <E T="03">FERC Contact:</E>
                     Claire Rozdilski at 202-502-8259; or email at 
                    <E T="03">claire.rozdilski@ferc.gov</E>
                    .
                </P>
                <P>
                    j. 
                    <E T="03">Deadline for filing motions to intervene and protests:</E>
                     60 days from the issuance date of this notice.
                </P>
                <P>
                    The Commission strongly encourages electronic filing. Please file motions to intervene and protests using the Commission's eFiling system at 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling.aspx</E>
                    . For assistance, please contact FERC Online Support at 
                    <E T="03">FERCOnlineSupport@ferc.gov,</E>
                     (866) 208-3676 (toll free), or (202) 502-8659 (TTY). In lieu of electronic filing, you may send a paper copy. Submissions sent via the U.S. Postal Service must be addressed to: Debbie-Anne A. Reese, Acting Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Room 1A, Washington, DC 20426. Submissions sent via any other carrier must be addressed to: Debbie-Anne A. Reese, Acting Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, Maryland 20852. All filings must clearly identify the project name and docket number on the first page: Schoolfield Hydroelectric Project (P-2411-030).
                </P>
                <P>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.</P>
                <P>k. This application has been accepted but is not ready for environmental analysis at this time.</P>
                <P>
                    l. 
                    <E T="03">The Schoolfield Project includes:</E>
                     (1) a 910-foot-long, 25-foot-high curved ogee-type concrete spillway dam with a crest elevation of 434.7 feet National Geodetic Vertical Datum of 1929 (NGVD29) and topped with 3-foot-high wooden flashboards; (2) a reservoir having a surface area of 287 acres and a gross storage capacity of approximately 1,952 acre-feet at the project's normal maximum water surface elevation of 437.7 feet NGVD29; (3) a 224-foot-long by 35-foot-wide brick and concrete powerhouse that contains three identical 1.5-megawatt (MW) generating units (each generating unit is connected to two identical propeller-type turbine units with rated capacity of 1,006 horsepower each) for a total installed capacity of 4.5 MW; (4) a 72-foot-long headwall between the dam and the powerhouse with six low-level sluice gates and a non-operating fish ladder; (5) a tailrace that is approximately 160 feet long and 220 feet wide and separated from main river flows by a concrete wall; (6) a substation; (7) six 300-foot-long generator leads and a step-up transformer; and (8) appurtenant facilities.
                </P>
                <P>The Schoolfield Project is operated in run-of-river mode, which may be suspended during reservoir drawdown and refilling for inspection of the City of Danville, Virginia's water supply intakes, which occurs on an as needed basis. During normal operation, an instantaneous minimum flow of 300 cubic feet per second is released downstream. The minimum flow is typically provided as part of generation flows. Average annual generation at the project was 15,220 megawatt-hours from 2017-2020.</P>
                <P>
                    m. A copy of the application is available for review via the internet through the Commission's Home Page (
                    <E T="03">http://www.ferc.gov</E>
                    ), using the “eLibrary” link. Enter the docket number, excluding the last three digits in the docket number field, to access the document. For assistance, contact FERC at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll free, (886) 208-3676 or TTY (202) 502-8659.
                </P>
                <P>
                    You may also register online at 
                    <E T="03">https://ferconline.ferc.gov/FERCOnline.aspx</E>
                     to be notified via email of new filings and issuances related to this or other pending projects. For assistance, contact FERC Online Support.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members, and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595, or 
                    <E T="03">OPP@ferc.gov</E>
                    .
                </P>
                <P>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.</P>
                <P>
                    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 
                    <PRTPAGE P="8669"/>
                    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.
                </P>
                <P>
                    o. 
                    <E T="03">Procedural schedule:</E>
                     The application will be processed according to the following schedule. Revisions to the schedule will be made as appropriate.
                </P>
                <P>
                    <E T="03">Issue Scoping Document 1 for comments:</E>
                     April 2024.
                </P>
                <P>
                    <E T="03">Scoping Document 1 comments due:</E>
                     May 2024.
                </P>
                <P>
                    <E T="03">Request Additional Information (if necessary):</E>
                     June 2024.
                </P>
                <P>
                    <E T="03">Issue Scoping Document 2 (if necessary):</E>
                     June 2024.
                </P>
                <P>
                    <E T="03">Issue Notice of Ready for Environmental Analysis:</E>
                     June 2024.
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02605 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <SUBJECT>Combined Notice of Filings #3</SUBJECT>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-1585-024; ER10-1594-024; ER10-1617-024; ER10-1626-015; ER10-1628-024; ER10-1632-026; ER12-60-026; ER14-2945-001; ER15-1747-001; ER15-1748-001; ER15-1749-001; ER15-1754-001; ER16-733-015; ER16-1148-015; ER17-554-001; ER18-1960-007; ER23-1220-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     High Point Solar LLC, Tenaska Pennsylvania Partners, LLC, Wolf Run Energy LLC, Tenaska Energía de Mexico, S. de R. L. de C.V.,LQA, LLC, Alpaca Energy LLC, Oxbow Creek Energy LLC, Milan Energy LLC, Beaver Dam Energy LLC, Roundtop Energy LLC, Tenaska Power Management, LLC, Tenaska Power Services Co., Texas Electric Marketing, LLC, Tenaska Virginia Partners, L.P., New Mexico Electric Marketing, LLC, California Electric Marketing, LLC, Alabama Electric Marketing, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Alabama Electric Marketing, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5629.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-1586-012; ER10-1630-012.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Wolf Hills Energy, LLC, Big Sandy Peaker Plant, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Big Sandy Peaker Plant, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5624.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2596-014; ER12-2200-010.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mehoopany Wind Energy LLC, Fowler Ridge II Wind Farm LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Fowler Ridge II Wind Farm LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5630.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER11-2044-043; ER10-1520-014; ER10-1521-014; ER10-1522-009; ER12-162-036; ER13-1266-049; ER15-2211-046; ER20-2493-009; ER21-2280-006; ER22-1385-008; ER23-674-005; ER23-676-005.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     BHE Power Watch, LLC, BHE Wind Watch, LLC, BHER Market Operations, LLC., Independence Wind Energy LLC, OTCF, LLC, MidAmerican Energy Services, LLC, CalEnergy, LLC, Bishop Hill Energy II LLC, Occidental Chemical Corporation, Occidental Power Marketing, L.P., Occidental Power Services, Inc., MidAmerican Energy Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of MidAmerican Energy Company, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5626.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER21-1755-007; ER23-1642-004; ER14-2498-015; ER14-2500-015.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Newark Energy Center, LLC, Hartree-Meadowlands Newark, LLC, NE Renewable Power, LLC, Hartree Partners, LP.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Hartree Partners, LP, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5632.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER23-2091-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Goleta Energy Storage, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Goleta Energy Storage, LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5631.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER23-2507-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Central Hudson Gas &amp; Electric Corporation, New York Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: Central Hudson Gas &amp; Electric Corporation submits tariff filing per 35: Central Hudson Compliance: Rate Schedule 19 Formula Rate Template to be effective 9/27/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5050.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER23-2716-001; ER21-2445-003.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Glacier Sands Wind Power, LLC, Moraine Sands Wind Power, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Moraine Sands Wind Power, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5623.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-433-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Flat Ridge 4 Wind, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: Filing of Shared Facilities Agreement Actual Rate Schedule Effective Date to be effective N/A.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5056.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-434-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Flat Ridge 5 Wind Energy LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: Filing of Shared Facilities Agreement Actual Rate Schedule Effective Date to be effective N/A.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5057.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-792-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Request to Defer Action on Amendment to WMPA, SA No. 6731; Queue No. AE2-248 to be effective 12/31/9998.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5131.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1181-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Pacific Gas and Electric Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Termination of Service Agreement No. 110 under Pacific Gas and Electric Company's FERC Electric Tariff Volume No. 5.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5627.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1182-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: 2024-02-02_SA 3114 Entergy Arkansas-Walnut Bend Solar 2nd Rev GIA (J552) to be effective 1/23/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                    <PRTPAGE P="8670"/>
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5054.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1183-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Fanfare Energy, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: Fanfare Energy, LLC MBR Tariff Application to be effective 4/3/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5089.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1184-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: 2024-02-02_Credit enhancements on Alternative Capitalization and MPD to be effective 5/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5096.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1185-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Duke Energy Florida, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: DEF—Bartow—Notice of Cancellation of RS No. 378 to be effective 4/3/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5126.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1186-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Original CSA, Service Agreement No. 7162; Queue No. AE1-093 to be effective 1/3/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240202-5128.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/23/24.
                </P>
                <P>
                    The filings are accessible in the Commission's eLibrary system (
                    <E T="03">https://elibrary.ferc.gov/idmws/search/fercgensearch.asp</E>
                    ) by querying the docket number.
                </P>
                <P>Any person desiring to intervene, to protest, or to answer a complaint in any of the above proceedings must file in accordance with Rules 211, 214, or 206 of the Commission's Regulations (18 CFR 385.211, 385.214, or 385.206) 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.</P>
                <P>
                    eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at: 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling/filing-req.pdf</E>
                    . For other information, call (866) 208-3676 (toll free). For TTY, call (202) 502-8659.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov</E>
                    . 
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024. </DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02602 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <DEPDOC>[Docket No. CP23-513-000]</DEPDOC>
                <SUBJECT>Port Arthur Pipeline, LLC; Notice of Availability of the Environmental Assessment for the Proposed Louisiana Connector Pipeline Amendment</SUBJECT>
                <P>The staff of the Federal Energy Regulatory Commission (FERC or Commission) has prepared an environmental assessment (EA) for the Louisiana Connector Pipeline Amendment, proposed by Port Arthur Pipeline, LLC (PAPL) in the above-referenced docket. PAPL requests authorization to make modifications to its previously authorized Louisiana Connector Project pipeline, construction footprint, and installation methods in 38 locations. The Louisiana Connector Project was approved by the Commission on April 18, 2019, in Docket No. CP18-7-000.</P>
                <P>The EA assesses the potential environmental effects of the construction and operation of the Louisiana Connector Pipeline Amendment in accordance with the requirements of the National Environmental Policy Act (NEPA). The FERC staff concludes that approval of the proposed amendment, with appropriate mitigating measures, would not constitute a major Federal action significantly affecting the quality of the human environment.</P>
                <P>The U.S. Army Corps of Engineers participated as a cooperating agency in the preparation of the EA. Cooperating agencies have jurisdiction by law or special expertise with respect to resources potentially affected by the proposal and participate in the NEPA analysis.</P>
                <P>The proposed amended facilities are specific to 38 locations in Jefferson County, Texas and Cameron, Calcasieu, Beauregard, and Allen Parishes, Louisiana (between milepost 0 and milepost 82.5), as detailed below:</P>
                <P>• modifications to pipeline routes, construction methods, horizontal directional drill (HDD) entry points, and additional temporary workspaces to accommodate landowner requests, reduce environmental impacts, avoid newly identified non-PAPL pipelines and new structures, and allow for safe construction access;</P>
                <P>• shifting of pipeline permanent easements to abut other existing easements;</P>
                <P>• addition and modification of access roads for HDD construction and inspection;</P>
                <P>• modification of storage and staging areas to utilize areas that were recently and permanently impacted by other parties;</P>
                <P>• modification of access roads due to obstructions and removal of access roads no longer required;</P>
                <P>• modification to water approaches to use existing boat ramp/dock improvements;</P>
                <P>• relocation of mainline valves to facilitate operations and maintenance, provide for safer road access, and access to power and communication facilities;</P>
                <P>• modification of three waterbody crossings methods from open cut to an HDD as requested by the U.S. Army Corps of Engineers;</P>
                <P>• combination, in two locations, of multiple HDDs into a single HDD to avoid an open-cut crossing and eliminate an HDD; and</P>
                <P>• modification of HDD alignments to avoid conflicts with potential future deeper canal depths.</P>
                <P>
                    The Commission mailed a copy of the 
                    <E T="03">Notice of Availability</E>
                     of this EA to Federal, State, and local government representatives and agencies; elected officials; environmental and public interest groups; Native American tribes; potentially affected landowners and other interested individuals and groups; and newspapers and libraries in the amended project area. The EA is only available in electronic format. It may be viewed and downloaded from the FERC's website (
                    <E T="03">www.ferc.gov</E>
                    ), on the natural gas environmental documents page (
                    <E T="03">https://www.ferc.gov/industries-data/natural-gas/environment/environmental-documents</E>
                    ). In addition, the EA may be accessed by using the eLibrary link on the FERC's website. Click on the eLibrary link (
                    <E T="03">https://elibrary.ferc.gov/eLibrary/search</E>
                    ), select “General Search” and enter the docket number in the “Docket Number” field, excluding the last three digits (
                    <E T="03">i.e.,</E>
                     CP23-513). Be sure you have selected 
                    <PRTPAGE P="8671"/>
                    an appropriate date range. For assistance, please contact FERC Online Support at 
                    <E T="03">FercOnlineSupport@ferc.gov</E>
                     or toll free at (866) 208-3676, or for TTY, contact (202) 502-8659.
                </P>
                <P>The EA 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 EA may do so. Your comments should focus on the EA's disclosure and discussion of potential environmental effects, reasonable alternatives, and measures to avoid or lessen environmental impacts. The more specific your comments, the more useful they will be. To ensure that the Commission has the opportunity to consider your comments prior to making its decision on this amendment, it is important that we receive your comments in Washington, DC, on or before 5:00 p.m. Eastern Time on March 4, 2024.</P>
                <P>
                    For your convenience, there are three methods you can use to file your comments to the Commission. The Commission encourages electronic filing of comments and has staff available to assist you at (866) 208-3676 or 
                    <E T="03">FercOnlineSupport@ferc.gov</E>
                    . Please carefully follow these instructions so that your comments are properly recorded.
                </P>
                <P>
                    (1) You can file your comments electronically using the eComment feature on the Commission's website (
                    <E T="03">www.ferc.gov</E>
                    ) under the link to FERC Online. This is an easy method for submitting brief, text-only comments on a project;
                </P>
                <P>
                    (2) You can also file your comments electronically using the eFiling feature on the Commission's website (
                    <E T="03">www.ferc.gov</E>
                    ) under the link to FERC Online. With eFiling, you can provide comments in a variety of formats by attaching them as a file with your submission. New eFiling users must first create an account by clicking on “eRegister.” You must select the type of filing you are making. If you are filing a comment on a particular project, please select “Comment on a Filing”; or
                </P>
                <P>(3) You can file a paper copy of your comments by mailing them to the Commission. Be sure to reference the amended project docket number (CP23-513-000) on your letter. Submissions sent via the U.S. Postal Service must be addressed to: Debbie-Anne A. Reese, Acting Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Room 1A, Washington, DC 20426. Submissions sent via any other carrier must be addressed to: Debbie-Anne A. Reese, Acting Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, MD 20852.</P>
                <P>
                    Filing environmental comments will not give you intervenor status, but you do not need intervenor status to have your comments considered. Only intervenors have the right to seek rehearing or judicial review of the Commission's decision. At this point in this proceeding, the timeframe for filing timely intervention requests has expired. Any person seeking to become a party to the proceeding must file a motion to intervene out-of-time pursuant to Rule 214(b)(3) and (d) of the Commission's Rules of Practice and Procedures (18 CFR 385.214(b)(3) and (d)) and show good cause why the time limitation should be waived. Motions to intervene are more fully described at 
                    <E T="03">https://www.ferc.gov/how-intervene</E>
                    .
                </P>
                <P>
                    Additional information about the amendment is available from the Commission's Office of External Affairs, at (866) 208-FERC, or on the FERC website (
                    <E T="03">www.ferc.gov</E>
                    ) using the eLibrary link. The eLibrary link also provides access to the texts of all formal documents issued by the Commission, such as orders, notices, and rulemakings.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov</E>
                    .
                </P>
                <P>
                    In addition, the Commission offers a free service called eSubscription which 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 
                    <E T="03">https://www.ferc.gov/ferc-online/overview</E>
                     to register for eSubscription.
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02607 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <SUBJECT>Combined Notice of Filings #1</SUBJECT>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2137-030; ER10-2131-030; ER10-2138-031; ER10-2139-031; ER10-2140-030; ER10-2141-030; ER14-2187-024; ER14-2799-021; ER15-103-015; ER18-140-014; ER21-258-007; ER22-2144-006; ER22-2474-002; ER22-2475-002; ER23-2668-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Richfield Solar Energy LLC, Top Hat Wind Energy Holdings LLC, Top Hat Wind Energy LLC, Invenergy Nelson Expansion LLC, Todd Solar LLC, Lackawanna Energy Center LLC, Invenergy Nelson LLC, Beech Ridge Energy Storage LLC, Grand Ridge Energy Storage LLC, Grand Ridge Energy V LLC, Grand Ridge Energy IV LLC, Grand Ridge Energy III LLC, Grand Ridge Energy II LLC, Grand Ridge Energy LLC, Beech Ridge Energy LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Beech Ridge Energy LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5611.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2475-031; ER10-1520-013; ER10-1521-013; ER10-2474-030; ER10-3246-024; ER13-1266-048; ER15-2211-045; ER20-2493-008; ER22-1385-007; ER23-674-004; ER23-676-004.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     BHE Power Watch, LLC,BHE Wind Watch, LLC,BHER Market Operations, LLC.,OTCF, LLC, MidAmerican Energy Services, LLC, CalEnergy, LLC, PacifiCorp, Sierra Pacific Power Company, Occidental Power Marketing, L.P., Occidental Power Services, Inc., Nevada Power Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Nevada Power Company, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5622.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2727-008; ER10-1451-010; ER10-1467-011; ER10-1469-011; ER10-1473-011; ER10-1474-011; ER10-1478-013; ER10-2687-010; ER10-2688-013; ER10-2689-014; ER10-2728-012; ER11-3907-004.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     The Toledo Edison Company, Green Valley Hydro, LLC, West Penn Power Company, The Potomac Edison Company, Monongahela Power Company, Pennsylvania Electric Company, 
                    <PRTPAGE P="8672"/>
                    Metropolitan Edison Company, Pennsylvania Power Company, The Cleveland Electric Illuminating Company, Ohio Edison Company, Jersey Central Power &amp; Light, Allegheny Energy Supply Company, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Allegheny Energy Supply Company, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5620.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER11-4436-011; ER10-2472-011; ER10-2473-012.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Cheyenne Light, Fuel and Power Company, Black Hills Wyoming, LLC, Black Hills Power, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Black Hills Power, Inc., et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5621.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER11-4626-004.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mt. Poso Generation Company, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Mt. Poso Cogeneration Company.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5615.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER17-1394-009; ER10-1328-005; ER10-1330-010; ER10-1331-005; ER10-1332-005; ER10-1427-009; ER10-2460-023; ER10-2461-024; ER10-2522-006; ER10-2567-006; ER10-2917-027; ER10-2918-026; ER10-2920-026; ER10-2922-027; ER11-2383-023; ER12-161-029; ER12-645-028; ER12-682-024; ER12-1502-008; ER12-1504-008; ER12-2313-008; ER13-17-022; ER13-1139-025; ER14-25-023; ER14-1964-019; ER14-2630-018; ER16-61-005; ER16-63-005; ER16-64-005; ER16-141-007; ER16-287-013; ER16-355-005; ER16-2527-005; ER17-2-006; ER17-360-004; ER17-361-004; ER17-362-004; ER17-482-013; ER17-539-003; ER17-540-003; ER17-2336-008; ER19-89-001; ER19-529-015; ER19-1074-015; ER19-1075-015; ER19-2684-003; ER20-1447-009; ER20-1487-004; ER20-1806-006; ER20-2028-004; ER22-192-008; ER22-398-002; ER22-1010-007; ER22-1627-003; ER22-1883-003; ER22-2042-003; ER23-921-002; ER23-1889-001; ER23-1939-002; ER23-2203-002; ER23-2363-002; ER23-2481-002; ER24-443-001; ER24-444-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Deriva Energy Beckjord Storage LLC, Deriva Energy Services, LLC, Crystal Hill Solar, LLC, HXOap Solar One, LLC, Wildflower Solar, LLC, Pike Solar LLC, Sweetland Wind Farm, LLC, Black Mesa Energy, LLC, Jackpot Holdings, LLC, Ledyard Windpower, LLC, AM Wind Repower LLC, TerraForm IWG Acquisition Holdings II, LLC, Mesa Wind Power LLC, Evolugen Trading and Marketing LP, Bitter Ridge Wind Farm, LLC, Catalyst Old River Hydroelectric Limited Partnership, Frontier Windpower II, LLC, Brookfield Energy Marketing US LLC, Palmer Solar, LLC, Brookfield Renewable Energy Marketing US LLC, Brookfield Energy Marketing Inc., Brookfield Renewable Trading and Marketing LP, North Rosamond Solar, LLC, Shoreham Solar Commons LLC, Wildwood Solar II, LLC, Wildwood Solar I, LLC,BREG Aggregator LLC, Rio Bravo Solar II, LLC, Pumpjack Solar I, LLC, Rio Bravo Solar I, LLC, Frontier Windpower, LLC, Caprock Solar I LLC, Colonial Eagle Solar, LLC, BIF III Holtwood LLC, Conetoe II Solar, LLC, Tallbear Seville LLC, Seville Solar Two, LLC, Seville Solar One LLC, Regulus Solar, LLC,LSP Safe Harbor Holdings, LLC, Prairie Breeze Wind Energy LLC, Imperial Valley Solar 1, LLC, Niagara Wind Power, LLC, Laurel Hill Wind Energy, LLC, Cimarron Windpower II, LLC, Ironwood Windpower, LLC, Erie Wind, LLC, California Ridge Wind Energy LLC, Bishop Hill Energy LLC, Safe Harbor Water Power Corporation, Hawks Nest Hydro LLC, Erie Boulevard Hydropower, L.P., Carr Street Generating Station, L.P., Brookfield Power Piney &amp; Deep Creek LLC, Kit Carson Windpower, LLC, Top of the World Wind Energy, LLC, Canandaigua Power Partners II, LLC, Canandaigua Power Partners, LLC, Brookfield Energy Marketing LP, Three Buttes Windpower, LLC, Silver Sage Windpower, LLC, North Allegheny Wind, LLC, Happy Jack Windpower, LLC, 83WI 8me, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of 83WI 8me, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5619.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER19-1865-003; ER19-1866-003; ER19-1867-003; ER19-1868-003; ER19-1869-003; ER19-1870-003; ER19-1871-003; ER19-1872-003; ER19-2140-004; ER19-2141-004; ER19-2142-004; ER19-2143-004; ER19-2144-004; ER19-2145-004; ER19-2146-004; ER19-2147-004; ER19-2148-005.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Heritage Power Marketing, LLC, Mountain Power, LLC, Warren Generation, LLC, Portland Power, LLC, Sayreville Power, LLC, Gilbert Power, LLC, Brunot Island Power, LLC, New Castle Power, LLC, Shawville Power, LLC, Tolna Power, LLC, Titus Power, LLC, Shawnee Power, LLC, Orrtanna Power, LLC, Niles Power, LLC, Hunterstown Power, LLC, Hamilton Power, LLC, Blossburg Power, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Blossburg Power, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5612.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER19-2716-003; ER19-2717-003; ER20-1398-002; ER20-1399-003; ER21-2722-003; ER21-2886-003; ER21-2887-002; ER22-1884-001; ER22-1885-002; ER23-1504-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Partin Solar LLC, South Portland ESS, LLC, Sanford ESS, LLC, Leicester Street Solar, LLC, Old Middleboro Road Solar, LLC, E. BarreCo Corp LLC, Rumford ESS, LLC, Ocean State BTM, LLC, Madison ESS, LLC, Madison BTM, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of Madison BTM, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5610.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER22-2784-003; ER14-41-010; ER14-42-010; ER16-498-009; ER16-499-009; ER16-500-009; ER16-2277-003; ER16-2289-004; ER18-1174-004; ER20-2448-005; ER21-133-005; ER21-736-006; ER21-1962-006; ER21-2634-004.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Solar Star Lost Hills, LLC, Mulberry BESS LLC, RE Slate 1 LLC, HDSI, LLC, American Kings Solar, LLC, Imperial Valley Solar 2, LLC, Golden Fields Solar I, LLC, Solar Star California XLI, LLC, RE Mustang 4 LLC, RE Mustang 3 LLC, RE Mustang LLC, RE Rosamond Two LLC, RE Rosamond One LLC, MN8 Energy Marketing LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of MN8 Energy Marketing LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5613.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER23-1772-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Fox Squirrel Solar LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Fox Squirrel Solar LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5616.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER23-2947-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc., Montana-Dakota Utilities Co.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Midcontinent Independent System Operator, Inc. submits tariff filing per 35.17(b): 2024-02-01_Additional Amendment MDU Depreciation Rates related to Retail Rates to be effective 10/1/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                    <PRTPAGE P="8673"/>
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5110.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                     The filings are accessible in the Commission's eLibrary system (
                    <E T="03">https://elibrary.ferc.gov/idmws/search/fercgensearch.asp</E>
                    ) by querying the docket number.
                </P>
                <P>Any person desiring to intervene, to protest, or to answer a complaint in any of the above proceedings must file in accordance with Rules 211, 214, or 206 of the Commission's Regulations (18 CFR 385.211, 385.214, or 385.206) 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.</P>
                <P>
                    eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at: 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling/filing-req.pdf</E>
                    . For other information, call (866) 208-3676 (toll free). For TTY, call (202) 502-8659.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov</E>
                    .
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02608 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <SUBJECT>Combined Notice of Filings #2</SUBJECT>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1170-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Amendment to ISA, Service Agreement No. 3634; Queue No. S14 to be effective 4/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5157.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1171-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Duke Energy Carolinas, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: DEC—South Carolina Public Service Authority Reimbursement Agreement RS No. 637 to be effective 4/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5160.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1172-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Avista Corporation.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Avista Corp RS T1215 Interconnected System Agmt BPA to be effective 4/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5168.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1173-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc., American Transmission Company LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Midcontinent Independent System Operator, Inc. submits tariff filing per 35.13(a)(2)(iii: 2024-02-01_SA 4237 ATC-WPL PCA (Grant County) to be effective 4/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5173.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1174-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Notice of Cancellation of WMPA, SA No. 6084; Queue No. AF2-292 re: withdrawal to be effective 4/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5180.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1175-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     NSTAR Electric Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Hingham Municipal Lighting Plant Facilities Support Agreement to be effective 2/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5183.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1176-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Southern California Edison Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Second Amendment GIA &amp; DSA, Rhodia (WDT891/SA Nos. 472-473) to be effective 2/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5185.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1177-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Central Maine Power Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: Request for Approval of New Electric Delivery Rate Schedule for Energy Storage to be effective 2/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5191.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1178-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Cancellation of WMPA, Service Agreement No. 5741; AF2-430 to be effective 4/2/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5198.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-1179-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: 2024-02-01_Att X, Appendix 6-Inverter Based Resources to be effective 4/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     2/1/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240201-5203.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/22/24.
                </P>
                <P>Take notice that the Commission received the following electric securities filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ES24-21-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Keystone Appalachian Transmission Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application Under Section 204 of the Federal Power Act for Authorization to Issue Securities of Keystone Appalachian Transmission Company.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5617.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ES24-22-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mid-Atlantic Interstate Transmission, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application Under Section 204 of the Federal Power Act for Authorization to Issue Securities of Mid-Atlantic Interstate Transmission, LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/31/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240131-5618.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/21/24.
                </P>
                <P>
                    The filings are accessible in the Commission's eLibrary system (
                    <E T="03">https://elibrary.ferc.gov/idmws/search/fercgensearch.asp</E>
                    ) by querying the docket number.
                </P>
                <P>Any person desiring to intervene, to protest, or to answer a complaint in any of the above proceedings must file in accordance with Rules 211, 214, or 206 of the Commission's Regulations (18 CFR 385.211, 385.214, or 385.206) 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.</P>
                <P>
                    eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings 
                    <PRTPAGE P="8674"/>
                    can be found at: 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling/filing-req.pdf.</E>
                     For other information, call (866) 208-3676 (toll free). For TTY, call (202) 502-8659.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02609 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[EPA-HQ-OPP-2024-0035; FRL-11721-01-OCSPP]</DEPDOC>
                <SUBJECT>DQB Males (Wolbachia pipientis, DQB Strain, Contained in Live Adult Culex quinquefasciatus Males); Receipt of Application for Emergency Exemption, Solicitation of Public Comment</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        EPA has received a specific exemption renewal request from the Hawaii Department of Agriculture for use of the pesticide DQB Males (
                        <E T="03">Wolbachia pipientis,</E>
                         DQB strain, contained in live adult 
                        <E T="03">Culex quinquefasciatus</E>
                         males), to treat up to 20,000 acres of State, Federal, and private wildlife conservation areas throughout the State of Hawaii to control 
                        <E T="03">Culex quinquefasciatus</E>
                         mosquitoes, a vector of avian malaria. The applicant proposes a new use of a microbial pesticide which has not been registered by EPA. Therefore, in accordance with the Code of Federal Regulations, EPA is soliciting public comment before making the decision whether to grant the exemption.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before February 23, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, identified by docket identification (ID) number EPA-HQ-OPP-2024-0035, and the specific case number for the chemical substance related to your comment, through the 
                        <E T="03">Federal eRulemaking Portal</E>
                         at 
                        <E T="03">https://www.regulations.gov</E>
                        . Follow the online instructions for submitting comments. Do not submit electronically any information you consider to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. To make special arrangements for hand delivery or delivery of boxed information, please follow the instructions at 
                        <E T="03">https://www.epa.gov/dockets/contacts.html</E>
                        . Additional instructions on commenting or visiting the docket, along with more information about dockets generally, is available at 
                        <E T="03">https://www.epa.gov/dockets</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Charles Smith, Registration Division (7505T), Office of Pesticide Programs, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001; main telephone number: (703) 305-7090; email address: 
                        <E T="03">RDFRNotices@epa.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. General Information</HD>
                <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                <P>
                    You may be potentially affected by this action if you are a pesticide manufacturer, North American Industrial Classification System (NAICS) (Code 32532) or involved with Hawaiian wildlife conservation areas that have known populations of 
                    <E T="03">Culex quinquefasciatus</E>
                    . This listing is not intended to be exhaustive, but rather provides a guide to help readers determine whether this document applies to them. Other types of entities not listed could also be affected.
                </P>
                <HD SOURCE="HD2">B. What should I consider as I prepare my comments for EPA?</HD>
                <P>
                    1. 
                    <E T="03">Submitting CBI.</E>
                     Do not submit this information to EPA through 
                    <E T="03">www.regulations.gov</E>
                     or email. Clearly mark the part or all of the information that you claim to be CBI. For CBI information in a disk or CD-ROM that you mail to EPA, mark the outside of the disk or CD-ROM as CBI and then identify electronically within the disk or CD-ROM the specific information that is claimed as CBI. In addition to one complete version of the comment that includes information claimed as CBI, a copy of the comment that does not contain the information claimed as CBI must be submitted for inclusion in the public docket. Information so marked will not be disclosed except in accordance with procedures set forth in 40 CFR part 2.
                </P>
                <P>
                    2. 
                    <E T="03">Tips for preparing your comments.</E>
                     When preparing and submitting your comments, see the commenting tips at 
                    <E T="03">https://www.epa.gov/dockets/commenting-epa-dockets</E>
                    .
                </P>
                <P>
                    3. 
                    <E T="03">Environmental justice.</E>
                     EPA seeks to achieve environmental justice, the fair treatment and meaningful involvement of any group, including minority and/or low- income populations, in the development, implementation, and enforcement of environmental laws, regulations, and policies. To help address potential environmental justice issues, the Agency seeks information on any groups or segments of the population who, as a result of their location, cultural practices, or other factors, may have atypical or disproportionately high and adverse human health impacts or environmental effects from exposure to the pesticide(s) discussed in this document, compared to the general population.
                </P>
                <HD SOURCE="HD1">II. What action is the Agency taking?</HD>
                <P>
                    Under section 18 of the Federal Insecticide, Fungicide, and Rodenticide Act (FIFRA) (7 U.S.C. 136p), at the discretion of the EPA Administrator, a Federal or State agency may be exempted from any provision of FIFRA if the EPA Administrator determines that emergency conditions exist which require the exemption. The Hawaii Department of Agriculture has requested the EPA Administrator to issue a specific exemption for the use of DQB males for conservation purposes to control mosquitoes (
                    <E T="03">Culex quinquefasciatus</E>
                    ), which are a known vector to avian malaria and threaten Hawaii's endemic forest bird population. Information in accordance with 40 CFR part 166 was submitted as part of this request.
                </P>
                <P>As part of this request, the applicant asserts that avian malaria was introduced into the Hawaiian Islands in the 19th century and spread by a non-native mosquito. Hawaii is experiencing increased mosquito populations that have significantly reduced Hawaiian bird populations. According to the applicant, without mosquito control, the survival and recovery of Hawaii's few remaining forest birds, including threatened and endangered species, are at imminent risk.</P>
                <P>
                    The applicant proposes to make 156 maximum applications of DQB male mosquitoes per release site per year based on an anticipated maximum of 3 releases per week. The total number of application days is a maximum of 156 during the year. The total amount of DQB Males to be applied per year to treat conservation lands throughout Hawaii is up to 3,000,000 male mosquitoes per week or 156,000,000 males per year. The maximum amount of 
                    <E T="03">Wolbachia pipientis,</E>
                     DQB strain, to 
                    <PRTPAGE P="8675"/>
                    be applied per year is up to ~1.83g/week or 95g/year.
                </P>
                <P>
                    This notice does not constitute a decision by EPA on the application itself. The regulations governing FIFRA section 18 require publication of a notice of receipt of an application for a specific exemption proposing a new use of a microbial pesticide (
                    <E T="03">i.e.,</E>
                     an active ingredient) which has not been registered by EPA. The notice provides an opportunity for public comment on the application.
                </P>
                <P>The Agency will review and consider all comments received during the comment period in determining whether to issue the specific exemption requested by the Hawaii Department of Agriculture.</P>
                <P>
                    <E T="03">Authority:</E>
                     7 U.S.C. 136 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Charles Smith,</NAME>
                    <TITLE>Director, Registration Division, Office of Pesticide Programs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02586 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[EPA-HQ-OPP-2023-0074; FRL-11590-01-OCSPP]</DEPDOC>
                <SUBJECT>Cancellation Order for Certain Pesticide Registrations and Amendments to Terminate Uses</SUBJECT>
                <HD SOURCE="HD2">Correction</HD>
                <P>In notice document 2023-28547, beginning on page 89448 in the issue of Wednesday, December 27, 2023, make the following correction:</P>
                <P>
                    On page 89449, in the first column, beginning on the 13th line beneath the “Section IV. Cancellation Order” the text “[INSERT DATE OF PUBLICATION IN THE 
                    <E T="04">Federal Register</E>
                    ]” should read “December 27, 2023”.
                </P>
            </PREAMB>
            <FRDOC>[FR Doc. C1-2023-28547 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 0099-10-D</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[EPA-HQ-OPP-2023-0607; FRL-11686-01-OCSPP]</DEPDOC>
                <SUBJECT>Pesticides; Flexible Packaging; Child Resistant Packaging Requirements; Notice of Availability</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Environmental Protection Agency (EPA) has determined that pesticide products marketed in flexible packaging (
                        <E T="03">e.g.,</E>
                         pouches) 20 fluid ounces or less in size with labeling either directly recommending residential use or reasonably interpreted to permit residential use are subject to the Child Resistant Packaging (CRP) mitigation measures, regardless of acute toxicity requirements, based on the visual similarity of the packaging design to children's food products. As such, pesticide applicants and registrants must comply with CRP for this packaging type at the size limits specified when labeled for or reasonably interpreted to permit residential use and EPA will evaluate applications for new products or amendments to currently registered products submitted to EPA under the Federal Insecticide, Fungicide and Rodenticide Act (FIFRA), as amended by the Pesticide Registration Improvement Act of 2022 (referred to as “PRIA 5”). Changes to packaging to implement CRP measures on existing products must be submitted as described in this document to allow for CRP data review. Additionally, the Agency is including recommended labeling mitigation for all flexible packaging, regardless of packaging size and intended use site.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>If a registrant has a registered pesticide product in flexible packaging that is not compliant with this determination, the registrant must contact the appropriate EPA Product Manager by August 6, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The docket for this action, identified by docket identification (ID) number EPA-HQ-OPP-2023-0607, is available online at 
                        <E T="03">https://www.regulations.gov.</E>
                         Additional information about dockets generally, along with instructions for visiting the docket in-person is available at 
                        <E T="03">https://www.epa.gov/dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Charles Smith, Registration Division (7505M), Office of Pesticide Programs, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001; telephone number: (703) 305-7090; email address: 
                        <E T="03">RDFRNotices@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Executive Summary</HD>
                <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                <P>
                    You may be potentially affected by this action if you currently market or propose to market a pesticide in flexible packaging (
                    <E T="03">e.g.,</E>
                     pouches). The following list of entities with North American Industrial Classification System (NAICS) codes is not intended to be exhaustive, but rather provides a guide to help readers determine whether this document applies to them. Potentially affected entities may include:
                </P>
                <P>• Crop production (NAICS code 111).</P>
                <P>• Animal production (NAICS code 112).</P>
                <P>• Food manufacturing (NAICS code 311).</P>
                <P>• Pesticide manufacturing (NAICS code 32532).</P>
                <HD SOURCE="HD2">B. What is the Agency's authority for taking this action?</HD>
                <P>
                    EPA is taking this action pursuant to the Federal Insecticide, Fungicide and Rodenticide Act (FIFRA), 7 U.S.C. 136 
                    <E T="03">et seq.,</E>
                     as amended by the Pesticide Registration Improvement Act of 2022 (referred to as “PRIA 5”), Public Law 117-328, and the packaging requirements for pesticides and devices promulgated in 40 CFR part 157.
                </P>
                <HD SOURCE="HD2">C. What action is the Agency taking?</HD>
                <P>
                    This document announces that EPA has determined pursuant to 40 CFR 157.22(a)(6) and (b), that pesticide products marketed in flexible packaging (
                    <E T="03">e.g.,</E>
                     pouches) in 20 fluid ounces or less in size with labeling either directly recommending residential use or reasonably interpreted to permit residential use are subject to the Child Resistant Packaging (CRP) mitigation measures, regardless of acute toxicity requirements, based on the visual similarity of the packaging design to children's food products. As such, pesticide applicants and registrants must comply with CRP for this packaging type at the size limits specified when labeled for or reasonably interpreted to permit residential use and EPA will evaluate applications for new products or amendments to currently registered products submitted to EPA under IFRA, as amended by PRIA 5. Changes to packaging to implement CRP measures on existing products must be submitted as described in this document to allow for CRP data review. Additionally, the Agency is including recommended labeling mitigation for all flexible packaging, regardless of packaging size and intended use site.
                </P>
                <HD SOURCE="HD1">II. Background</HD>
                <P>
                    EPA has seen an increased interest from pesticide manufacturers in the use of flexible packaging (
                    <E T="03">e.g.,</E>
                     pouches) to store and distribute products, especially insecticides and herbicides that residential users can dilute and apply to their lawn and garden. These packages contain a concentrated form of pesticide product, without added water, which ready-to-use (RTU) products typically contain. By removing the water, pesticide packaging is smaller and 
                    <PRTPAGE P="8676"/>
                    lighter, reducing plastic consumption and shipping costs.
                </P>
                <P>To date, EPA has not been made aware of incidents with children involving pesticides in flexible packaging, potentially due to the relatively new occurrence of such products on the market. However, due to multiple incidents involving children ingesting other toxic products that were sold in similar packaging resembling food products, as documented in public news sources, EPA has determined that there is potential for accidental injury or illness which CRP could reduce or prevent. The following is a list of case studies of this occurrence in other industries have been outlined:</P>
                <P>• Twelve elementary students in Alaska accidentally drank floor sealant in a product designed similar to milk containers (Ref. 1).</P>
                <P>• A nine-year-old boy accidentally ingested a `flame color changing' agent sold in packaging with a similar design to children's candy (Ref. 2).</P>
                <P>• Numerous news stories have reported children ingesting cannabis-infused sweets marketed to look similar to candy products (Refs. 3 through 7).</P>
                <P>Action taken by the Agency to mitigate risks associated with flexible packaging has precedent from other Federal agencies. For example, the sale of edible products containing Delta-8 THC in packaging almost identical to children's food products prompted the Federal Trade Commission (FTC) and U.S. Food and Drug Administration (FDA) to send Cease and Desist letters to six companies (Ref. 4).</P>
                <P>With this determination, the Agency intends to prevent similar inadvertent exposure to residential use pesticide products. The Agency also reminds registrants that, pursuant to FIFRA section 6(a)(2) and 40 CFR part 159, pesticide manufacturers are required to submit information regarding unreasonable adverse effects on the environment, including incidents affecting humans or other non-target organisms; such information must be submitted to EPA within 15 days after learning of any allegations involving human fatality and within 30 days after the end of each 30-day report accumulation for other human incidents.</P>
                <HD SOURCE="HD1">III. EPA Determination Regarding Flexible Packaging</HD>
                <HD SOURCE="HD2">A. CRP Requirements for Pesticides</HD>
                <P>
                    EPA sets standards for pesticide containers and labeling in 40 CFR parts 156 and 165, including design, construction, and labeling requirements to ensure safe and uniform packaging. To ensure pesticides are packaged in a manner safe for use around children, 40 CFR part 157 describes requirements for CRP on pesticide containers used in residential settings. CRP containers are designed and constructed to be significantly difficult for children under five years of age to open or obtain a toxic or harmful amount of the substance contained therein within a reasonable amount of time. Generally, pesticide products that meet the toxicity criteria in 40 CFR 157.22(a)(1) through (4) and are labeled for or reasonably interpreted to permit residential use as contemplated in 40 CFR 157.22(b), are required to be packaged in CRP, unless the products satisfy the exemptions of 40 CFR 157.24 (
                    <E T="03">e.g.,</E>
                     are restricted use products or are packaged in a large size).
                </P>
                <HD SOURCE="HD2">B. CRP Test Guidelines</HD>
                <P>Prior to a pesticide product being packaged and sold in CRP, the registrant must conduct, and submit to EPA for review and approval, CRP testing performed in accordance with the protocol specified at 16 CFR 1700.20. Selected child testers must be between the ages of 42-51 months. Children are presented an empty package for five minutes to test if they can open it. If after five minutes the child does not open the package, the test administrator will provide a physical demonstration without verbal instructions on how to open the package and then allow the child an additional five minutes to attempt to open the package. A test failure is defined as any a child who opens the special packaging or gains access to its contents.</P>
                <P>The sequential test is initially conducted using 50 children, and, depending on the results, it is determined whether the package is either child-resistant or not child-resistant or whether further testing is required. Further testing is required if the results are inconclusive and involves the use of one or more additional groups of 50 children each, up to a maximum of 200 children. If, after conducting the two 5-minute tests, fewer than 5 failures occur with the first 50 testers, then no further testing is required, and the package passes the Child Resistance Effectiveness test. If more than 6 or fewer than 14 failures occur with the first 50 testers, then further testing is required by testing an additional 50 testers. If more than 15 failures occur with the first 50 testers, then no further testing is required, and the packages fails the Child Resistance Effectiveness test.</P>
                <HD SOURCE="HD2">C. CRP for Flexible Packaging</HD>
                <P>
                    Packaging for products with a toxicity below the threshold specified in 40 CFR 157.22(a)(1) through (4) would not ordinarily trigger the requirement for CRP. However, EPA has determined under 40 CFR 157.22(a)(6) that pesticide products in flexible packaging resembling child food containers have characteristics that present a serious hazard of accidental injury or illness which CRP could reduce. As most children's food pouches are between 3 and 5 fluid ounces, the Agency believes that CRP measures on pesticide products 20 fluid ounces or less would provide a sufficient margin of protection to avoid children mistaking pesticidal flexible packaging for food pouches. While these products are relatively new to the market, flexible packaging containing pesticides are generally 1 to 54 fluid ounces. Flexible packaging that is larger than 20 fluid ounces are much larger than traditional children's food pouches and are unlikely to be mistaken by adults or children as food. This notice conveys that EPA has determined that, pursuant to 40 CFR 157.22(a)(6) and (b), pesticide products marketed in flexible packaging (
                    <E T="03">e.g.,</E>
                     pouches) 20 fluid ounces or less in size with labeling either directly recommending residential use or reasonably interpreted to permit residential use are subject to CRP mitigation measures under 40 CFR part 157, regardless of acute toxicity requirements, based on the visual similarity of the packaging design to children's food products.
                </P>
                <P>
                    This document further conveys to applicants and registrants that CRP is necessary for this packaging type at the size limits specified when labeled for or reasonably interpreted to permit residential use and will be evaluated for applications for new products or for amendment of currently registered products submitted under FIFRA section 33, 
                    <E T="03">i.e.,</E>
                     PRIA 5. Changes to packaging to implement CRP measures on existing products must be submitted as a PRIA R340/341, A572, or B680/681, not as a fast-track non-PRIA amendment, to allow for CRP data review.
                </P>
                <P>Changes in the shape, color, or composition of packaging and changes in labeling statements due to modification of package size and type may be done by notification only if all criteria in PRN 98-10 section II.E. are met. Due to the Agency's determination, products marketed in flexible packaging do not meet the following criteria in PRN 98-10 section II.E and may not modify the package size and type via notification:</P>
                <EXTRACT>
                    <PRTPAGE P="8677"/>
                    <FP>“. . . 3. Either before or after the proposed change, the product is neither subject to child resistant packaging (CRP), nor has the registrant voluntarily used CRP; [. . .]</FP>
                    <P>6. The package size is not reduced to the point that the net contents of the package is smaller than the dosage required by directions for use or that a reduced package size will require CRP;</P>
                    <P>
                        7. The package size or other characteristics is not changed in a way which violates EPA mandated restrictions imposed on a product (
                        <E T="03">e.g.,</E>
                         size limitations may be imposed on a product to limit its use to homeowners only).”
                    </P>
                </EXTRACT>
                <HD SOURCE="HD2">D. Additional Recommendations for Flexible Packaging and Labeling</HD>
                <P>In addition to determining that CRP requirements are necessary for pesticidal flexible packaging products 20 ounces or less in size with labeling either directly recommending residential use or reasonably interpreted to permit residential use, the following additional mitigation measures are recommended for all pesticide products sold in flexible packaging, regardless of size or intended use site:</P>
                <P>
                    • No child-attractant packaging colors (
                    <E T="03">e.g.,</E>
                     neon colors, bright colors, more than three colors). Packaging should be primarily in black, white, or grey.
                </P>
                <P>
                    • Flexible packaging (
                    <E T="03">e.g.,</E>
                     pouches) should be packaged by the manufacturer within an outer box containing the full product label for sale to the consumer.
                </P>
                <P>
                    • All product packaging (
                    <E T="03">e.g.,</E>
                     outer box and flexible packaging) should contain a graphic or icon stating, `Not A Food Product.'
                </P>
                <P>The following statements should be included in the Directions for Use section of the label:</P>
                <P>• `Store pouches in closed product box and away from children and food.'</P>
                <P>
                    <E T="03">For pouches 20 fluid ounces or less:</E>
                     `Each pouch is for one-time use only. Do not store any opened pouches. Empty the entire contents of the pouch into the container. Once empty, discard the empty pouch immediately into a secure trash receptacle that cannot be accessed by children.'
                </P>
                <P>
                    • 
                    <E T="03">For pouches greater than 20 fluid ounces:</E>
                     `Once empty, discard the empty pouch immediately into a secure trash receptacle that cannot be accessed by children.'
                </P>
                <HD SOURCE="HD2">E. Next Steps</HD>
                <P>These mitigation measures will be reflected in an updated version of the Label Review Manual to serve as guidance for registrants pursuing flexible packaging containers.</P>
                <P>As pesticides in flexible packaging is a relatively new occurrence, EPA does not believe that there are any registered pesticide products in flexible packaging without the CRP and mitigation language above. If a registrant has a registered pesticide product in flexible packaging that is not compliant with the determination as described in this document, the registrant must contact the appropriate EPA Product Manager by August 6, 2024.</P>
                <HD SOURCE="HD1">IV. References</HD>
                <P>
                    The following is a listing of the documents that are specifically referenced in this document. The docket includes these documents and other information considered by EPA, including documents that are referenced within the documents that are included in the docket, even if the referenced document is not physically located in the docket. For assistance in locating these other documents, please consult the technical person listed under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        1. Boyette, C. 2022. Alaska Schoolchildren Were Served Floor Sealant Instead Of Milk At A Child Care Program, School District Says. 
                        <E T="03">CNN.</E>
                         June 16, 2022. 
                        <E T="03">https://www.cnn.com/2022/06/16/us/alaska-students-floor-sealant-milk/index.html.</E>
                         Accessed on September 25, 2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        2. WRAL Staff. 2023. Boy, 9, Hospitalized After Mistaking Chemical For Candy. WAGM TV. January 11, 2023. 
                        <E T="03">https://www.wagmtv.com/2023/01/11/boy-9-hospitalized-after-mistaking-checmical-candy/.</E>
                         Accessed on September 25, 2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        3. Caron, C. 2022. More Young Kids Are Getting Sick From Cannabis Edibles. 
                        <E T="03">The New York Times.</E>
                         January 14, 2022. 
                        <E T="03">https://www.ncbi.nlm.nih.gov/search/research-news/15335/?utm_source=gquery&amp;utm_medium=referral&amp;utm_campaign=gquery-home.</E>
                         Accessed on September 25, 2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        4. U.S. Federal Trade Commission (FTC) and U.S. Food and Drug Administration (FDA), 2023. FTC Sends Cease and Desist Letters with FDA To Companies Selling Edible Products Containing Delta-8 THC in Packaging Nearly Identical to Food Children Eat. 
                        <E T="03">Federal Trade Commission.</E>
                         July 5, 2023. 
                        <E T="03">https://www.ftc.gov/news-events/news/press-releases/2023/07/ftc-sends-cease-desist-letters-fda-companies-selling-edible-products-containing-delta-8-thc.</E>
                         Accessed on 9/25/2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        5. Kaur, H. and D. Shepherd. 2020. Two Children Hospitalized After Eating THC-infused Candy Accidentally Given Out By A Local Food Bank. 
                        <E T="03">CNN.</E>
                         April 7, 2020. 
                        <E T="03">https://www.cnn.com/2020/04/06/us/children-thc-candy-food-bank-trnd/index.html.</E>
                         Accessed on September 25, 2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        6. Roberts, C. 2022. First The Girl Scouts, Now Pepsi: Why Big Brands Hate Marijuana. 
                        <E T="03">Forbes.</E>
                         April 30, 2022. 
                        <E T="03">https://www.forbes.com/sites/chrisroberts/2022/04/30/first-the-girl-scouts-now-pepsi-why-big-brands-hate-marijuana/?sh=5e7a10735108.</E>
                         Accessed on September 25, 2023.
                    </FP>
                    <FP SOURCE="FP-2">
                        7. Semley, J. 2023. Cartoon Packaging And An `Inconsolable' High: When Magic Mushroom Chocolate Gets Into The Wrong Hands. 
                        <E T="03">The Guardian.</E>
                         June 12, 2023. 
                        <E T="03">https://www.theguardian.com/society/2023/jun/12/mushrooms-chocolate-psilocybin-psychedelics-children.</E>
                         Accessed on September 25, 2023.
                    </FP>
                </EXTRACT>
                <P>
                    <E T="03">Authority:</E>
                     7 U.S.C. 136 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Edward Messina,</NAME>
                    <TITLE>Director, Office of Pesticide Programs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02587 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[EPA-HQ-OAR-2011-0742; FRL—11599-01-OAR]</DEPDOC>
                <SUBJECT>Information Collection Request; Comment Request; Air Pollution Regulations for Outer Continental Shelf (OCS) Activities</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA) is planning to submit an information collection request (ICR), “Air Pollution Regulations for Outer Continental Shelf (OCS) Activities” (EPA ICR No. 1601.10, OMB Control No. 2060-0249), to the Office of Management and Budget (OMB) for review and approval in accordance with the Paperwork Reduction Act (PRA). Before doing so, the EPA is soliciting public comments on specific aspects of the proposed information collection as described below. This is a proposed renewal of the ICR, which is currently approved through May 31, 2024. An Agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be submitted on or before April 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, referencing Docket ID No. EPA-HQ-OAR-2011-0724, online using 
                        <E T="03">www.regulations.gov</E>
                         (our preferred method), by email to 
                        <E T="03">a-and-r-docket@epa.gov,</E>
                         or by mail to: EPA Docket Center, Environmental Protection Agency, Mail Code 28221T, 1200 Pennsylvania Ave. NW, Washington, DC 20460.
                    </P>
                    <P>
                        EPA's policy is that all comments received will be included in the public 
                        <PRTPAGE P="8678"/>
                        docket without change including any personal information provided, unless the comment includes profanity, threats, information claimed to be Confidential Business Information or other information whose disclosure is restricted by statute.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ben Garwood, Air Quality Policy Division, Office of Air Quality Planning and Standards, C504-03, U.S. Environmental Protection Agency, Post Office Box 12055, Research Triangle Park, NC 27711; telephone number: (919) 541-1358; fax number: (919) 541-4028; email address: 
                        <E T="03">garwood.ben@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Supporting documents which explain in detail the information that the EPA will be collecting are available in the public docket for this ICR. The docket can be viewed online at 
                    <E T="03">https://www.regulations.gov</E>
                     or in person at the EPA Docket Center, WJC West, Room 3334, 1301 Constitution Ave. NW, Washington, DC. The telephone number for the Docket Center is (202) 566-1744. For additional information about EPA's public docket, visit 
                    <E T="03">https://www.epa.gov/dockets.</E>
                </P>
                <P>
                    Pursuant to section 3506(c)(2)(A) of the PRA, the 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, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of responses. The EPA will consider the comments received and amend the ICR as appropriate. The final ICR package will then be submitted to OMB for review and approval. At that time, the EPA will issue another 
                    <E T="04">Federal Register</E>
                     notice to announce the submission of the ICR to OMB and the opportunity to submit additional comments to OMB.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Section 328 of the Clean Air Act (CAA) gives the EPA responsibility for regulating air pollution from OCS sources located offshore of the states along the Atlantic and Pacific Coasts (except the North Slope Borough of Alaska), and along the eastern Gulf of Mexico coast (off the coast of Florida). In general, these OCS sources must obtain OCS permits complying with the EPA's preconstruction permit program (usually Prevention of Significant Deterioration (PSD) requirements) and title V operating permit program, and then maintain ongoing compliance with their permit conditions. Industry respondents include owners or operators of existing and new or modified OCS sources. These respondents must prepare permit applications and, after receiving their permits, conduct testing, monitoring, recordkeeping and reporting as required by their permits. The recordkeeping and reporting requirements are necessary so that the EPA can determine whether these sources are meeting all the requirements that apply to them. The EPA has delegated the authority to implement and enforce the OCS regulations to four local air pollution control agencies in California (Santa Barbara County Air Pollution Control District (SBCAPCD), South Coast Air Quality Management District (SCAQMD), Ventura County Air Pollution Control District (VCAPCD) and San Luis Obispo County Air Pollution Control District (SLOCAPCD)). The EPA has also delegated the authority to implement and enforce the OCS regulations for sources located off the coast to 3 state air pollutions control agencies: Delaware (DDNREC), Maryland (MDE), and Virginia (VDEQ). These agency respondents must review sources' permit applications and reports, issue permits, observe performance tests and conduct inspections to ensure that the sources off their coasts are meeting all the requirements that apply to them. Section 176(c) of the CAA (42 U.S.C. 7401 
                    <E T="03">et seq.</E>
                    ) requires that all federal actions conform with the State Implementation Plans to attain and maintain the National Ambient Air Quality Standards.
                </P>
                <P>Depending on the type of action, the federal entities must collect information themselves, hire consultants to collect the information or require applicants/sponsors of the federal action to provide the information.</P>
                <P>The type and quantity of information required will depend on the circumstances surrounding the action. First, the entity must make an applicability determination. If the source is located within 25 miles of the state's seaward boundary (Inner OCS) as established in the regulations, the requirements are the same as those that would be applicable if the source were located in the corresponding onshore area (COA). Sources locating beyond 25 nautical miles from the state seaward boundary (Outer OCS) are subject to federal air quality requirements which could include the EPA's PSD preconstruction permit program, Part 71 Title V operating permit program, New Source Performance Standards and some standards for Hazardous Air Pollutants promulgated under section 112 of the CAA. State and local air pollution control agencies are usually requested to provide information concerning regulation of offshore sources and are provided opportunities to comment on the proposed determinations. The public is also provided an opportunity to comment on the proposed determinations.</P>
                <P>
                    <E T="03">Form numbers:</E>
                     None.
                </P>
                <P>
                    <E T="03">Respondents/affected entities:</E>
                     Entities potentially affected by this action are those that must apply for and obtain an OCS permit pursuant the OCS permit program. In addition, state and local agencies that have been delegated authority to implement and enforce the OCS permit program, which must review permit applications and issue permits, are affected entities.
                </P>
                <P>
                    <E T="03">Respondent's obligation to respond:</E>
                     Mandatory [
                    <E T="03">see</E>
                     40 CFR part 55].
                </P>
                <P>
                    <E T="03">Estimated number of respondents:</E>
                     74 industrial facilities and 7 state and local permitting agencies.
                </P>
                <P>
                    <E T="03">Frequency of response:</E>
                     On occasion, as necessary.
                </P>
                <P>
                    <E T="03">Total estimated burden:</E>
                     36,001 hours (per year). Burden is defined at 5 CFR 1320.03(b).
                </P>
                <P>
                    <E T="03">Total estimated cost:</E>
                     $3,755,783.00 (per year) in addition to $55,268.00 annually in Operation and Maintenance costs and $325,104.00 in capital costs.
                </P>
                <P>
                    <E T="03">Changes in estimates:</E>
                     There is a projected increase of 15,778 hours in the total estimated respondent burden compared with the ICR most recently approved by OMB. This increase is primarily due the projected number of OCS sources subject to the program mainly related to alternative energy sources including new wind power farms along the eastern seaboard of the United States, and changes to burden estimates as noted in the excel spreadsheet in the docket for this notice titled “1601t10 Draft OCS ICR Burden Calculations 2024.”
                </P>
                <SIG>
                    <NAME>Scott Mathias,</NAME>
                    <TITLE>Director, Air Quality Policy Division.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02613 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8679"/>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[EPA-HQ-OAR-2024-0036; FRL-11690-01-OAR]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Proposed Information Collection Request; Comment Request; Climate Pollution Reduction Grants (CPRG) Program Implementation Grants ICR (NEW)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA) is planning to submit an information collection request (ICR), Climate Pollution Reduction Grants (CPRG) Program Implementation Grants ICR (NEW) (EPA ICR Number 2806.01, OMB Control Number 2060-NEW) to the Office of Management and Budget (OMB) for review and approval in accordance with the Paperwork Reduction Act. Before doing so, the EPA is soliciting public comments on specific aspects of the proposed information collection as described below. This is a request for approval of a new collection. This notice allows for 60 days for public comments.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be submitted on or before April 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, referencing Docket ID Number EPA-HQ-OAR-2024-0036, to EPA online using 
                        <E T="03">www.regulations.gov</E>
                         (our preferred method), by email to: 
                        <E T="03">a-and-r-docket@epa.gov,</E>
                         or by mail to: EPA Docket Center, Environmental Protection Agency, Mail Code 28221T, 1200 Pennsylvania Avenue NW, Washington, DC 20460. 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.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Pam Long, Air Quality Policy Division, Office of Air Quality Planning and Standards, Mailcode C504.1, Environmental Protection Agency, Post Office Box 12055 RTP, NC 27711; telephone number: (919) 541-0641; email address: 
                        <E T="03">long.pam@epa.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This is a request for approval of a new collection. An agency may not conduct or sponsor and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    This notice allows 60 days for public comments. Supporting documents, which explain in detail the information that the EPA will be collecting, are available in the public docket for this ICR. The docket can be viewed online at 
                    <E T="03">www.regulations.gov</E>
                     or in person at the EPA Docket Center, WJC West, Room 3334, 1301 Constitution Ave. NW, Washington, DC. The telephone number for the Docket Center is 202-566-1744. For additional information about EPA's public docket, visit 
                    <E T="03">http://www.epa.gov/dockets</E>
                    .
                </P>
                <P>
                    Pursuant to section 3506(c)(2)(A) of the PRA, the 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 forms of information technology. The EPA will consider the comments received and amend the ICR as appropriate. The final ICR package will then be submitted to OMB for review and approval. At that time, the EPA will issue another 
                    <E T="04">Federal Register</E>
                     notice to announce the submission of the ICR to OMB and the opportunity to submit additional comments to OMB.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The Climate Pollution Reduction Grants (CPRG) program was established under section 60114 of the Inflation Reduction Act (IRA) signed on August 16, 2022. Through a competitive process, EPA anticipates awarding $4.6B in CPRG implementation grants to States, municipalities, Tribes/Territories, and air quality management districts in 2024 to “facilitate the reduction of greenhouse gas air pollution.” Grantees will be required to report projected greenhouse gas (GHG) emission reductions as well as changes in other air pollutants, both in general and specifically in low-income and disadvantaged communities (LIDAC). This information will be collected to ensure accurate projections of GHGs and other air pollutant emissions both in and outside LIDAC areas for projects being funded under the CPRG program.
                </P>
                <P>
                    It is expected that the CPRG program, along with other IRA programs, will be required to demonstrate effective execution of the statutory responsibilities charged to EPA, as well as comply with any additional reporting requirements (
                    <E T="03">e.g.,</E>
                     Evidence Act, Justice40). These responsibilities necessitate standardized data collection from CPRG implementation grantees for the purposes of (1) determining the accuracy of calculations and analyses submitted by grantees, (2) assessing the compliance of grantees in performing tasks agreed to under the Terms and Conditions of CPRG implementation grants, and (3) applying information collected from CPRG implementation grantees for analytical use.
                </P>
                <P>
                    <E T="03">Form numbers:</E>
                     n/a.
                </P>
                <P>
                    <E T="03">Respondents/affected entities:</E>
                     CPRG Implementation Grant General Competition and Tribes/Territories Competition grantees.
                </P>
                <P>
                    <E T="03">Respondent's obligation to respond:</E>
                     Mandatory (to comply with CPRG grant Reporting Requirements/Terms and Conditions).
                </P>
                <P>
                    <E T="03">Estimated number of respondents:</E>
                     ~130.
                </P>
                <P>
                    <E T="03">Frequency of response:</E>
                     1-year (General Competition) and final reports (General and Tribal Competitions).
                </P>
                <P>
                    <E T="03">Total estimated burden:</E>
                     ~47,133 hours (per year). Burden is defined at 5 CFR 1320.03(b).
                </P>
                <P>
                    <E T="03">Total estimated cost:</E>
                     ~$2,905,406 (per year), which includes $0 annualized capital or operation &amp; maintenance costs.
                </P>
                <P>
                    <E T="03">Changes in the estimates:</E>
                     Not applicable, no current ICR.
                </P>
                <SIG>
                    <NAME>Scott Mathias,</NAME>
                    <TITLE>Director, Air Quality Policy Divison.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02614 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <DEPDOC>[OMB 3060-1048; FR ID 201372]</DEPDOC>
                <SUBJECT>Information Collection Being Reviewed by the Federal Communications Commission Under Delegated Authority</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        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 
                        <PRTPAGE P="8680"/>
                        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.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written PRA comments should be submitted on or before April 8, 2024. 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.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Direct all PRA comments to Cathy Williams, FCC, via email to 
                        <E T="03">PRA@fcc.gov</E>
                         and to 
                        <E T="03">Cathy.Williams@fcc.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>For additional information about the information collection, contact Cathy Williams at (202) 418-2918.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-1048.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Section 1.929(c)(1), Composite Interference Contour (CIC).
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     N/A.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities, not-for-profit institutions and state, local or tribal government.
                </P>
                <P>
                    <E T="03">Number of Respondents and Responses:</E>
                     50 respondents; 50 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     2 hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     On occasion reporting requirement.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for this information collection is contained in 47 U.S.C. 309(j).
                </P>
                <P>
                    <E T="03">Total Annual Burden:</E>
                     100 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     No cost.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The Commission will submit this expiring information collection to the Office of Management and Budget (OMB) for approval of an extension request.
                </P>
                <P>Under 47 CFR 1.929(c)(1) of the Commission's rules, any increase in the composite interference contour (CIC) of a site-based licensee in the Paging and Radiotelephone Service, Rural Radiotelephone Service, or 800 MHz Specialized Mobile Radio Service is a major modification of a license that requires prior Commission approval.</P>
                <P>However, in February 2005, the Commission adopted and released final rules which amended section 1.929(c)(1) to specify that expansion of a composite interference contour (CIC) of a site-based licensee in the Paging and Radiotelephone Service—as well as the Rural Radiotelephone Service and 800 MHz Specialized Mobile Radio Service—over water on a secondary, non-interference basis should be classified as a minor (rather than major) modification of a license. Such reclassification has eliminated the filing requirements associated with these license modifications, but requires site-based licensees to provide the geographic area licensee (on the same frequency) with the technical and engineering information necessary to evaluate the site-based licensee's operations over water.</P>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Marlene Dortch, </NAME>
                    <TITLE>Secretary, Office of the Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02571 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <DEPDOC>[OIA Docket No. 24-30-FR-ID-201045]</DEPDOC>
                <SUBJECT>Federal Advisory Committee, World Radiocommunication Conference Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of renewal of the charter for the World Radiocommunication Conference Advisory Committee.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In this document, the Federal Communications Commission (FCC or Commission) hereby announces that the charter of the World Radiocommunication Conference Advisory Committee (hereinafter Committee) has been renewed on January 31, 2024 for a two year period pursuant to the Federal Advisory Committee Act (FACA), following consultation with the Committee Management Secretariat, General Services Administration.</P>
                </SUM>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>45 L Street NE, Washington, DC 20554.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Gregory Baker, Designated Federal Official, at (202) 418-0611, 
                        <E T="03">WRC-27@fcc.gov,</E>
                         or 
                        <E T="03">Gregory.Baker@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>After consultation with the General Services Administration, the Commission renewed the charter on January 31, 2024, providing the Committee with authorization to operate for two years. The purpose of the Committee is to advise the Commission and to make recommendations for proposals for International Telecommunication Union (ITU) World Radiocommunication Conferences. The Committee will advise the Commission, and gather information and prepare technical analyses to support its advice. The Committee will report its findings to the Chairwoman of the Commission through the Committee's Designated Federal Official (DFO) or its Alternate DFO, upon request and in advance of the deadline established by the ITU for submission of proposals by administrations to WRC-27.</P>
                <HD SOURCE="HD1">Advisory Committee</HD>
                <P>
                    The Committee will be organized under, and will operate in accordance with, the provisions of the Federal Advisory Committee Act (FACA) (5 U.S.C. ch. 10). The Committee will be solely advisory in nature. Consistent with FACA and its requirements, each meeting of the Committee will be open to the public unless otherwise noticed. A notice of each meeting will be published in the 
                    <E T="04">Federal Register</E>
                     at least fifteen (15) days in advance of the meeting. Records will be maintained of each meeting and made available for public inspection. All activities of the Committee will be conducted in an open, transparent, and accessible manner. The Committee shall terminate two (2) years from the filing date of its charter, or earlier upon the completion of its work as determined by the Chairwoman of the FCC, unless its charter is renewed prior to the termination date. During the Committee's next term, it is anticipated that the Committee will meet in Washington, DC and/or virtually via video conference, at the discretion of the Commission, approximately four (4) times a year, with additional meetings scheduled as needed. The first meeting date and agenda topics will be described in a Public Notice issued and published in the 
                    <E T="04">Federal Register</E>
                     at least fifteen (15) days prior to the first meeting date. In addition, as needed, working groups or subcommittees will be established to 
                    <PRTPAGE P="8681"/>
                    facilitate the Committee's work between meetings of the full Committee. Meetings of the Committee will be fully accessible to individuals with disabilities.
                </P>
                <EXTRACT>
                    <FP>(5 U.S.C. 1009(a)(2))</FP>
                </EXTRACT>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Sarah Van Valzah,</NAME>
                    <TITLE>Assistant Chief, Office of International Affairs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02619 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL RESERVE SYSTEM</AGENCY>
                <SUBJECT>Change in Bank Control Notices; Acquisitions of Shares of a Bank or Bank Holding Company</SUBJECT>
                <P>The notificants listed below have applied under the Change in Bank Control Act (Act) (12 U.S.C. 1817(j)) and § 225.41 of the Board's Regulation Y (12 CFR 225.41) to acquire shares of a bank or bank holding company. The factors that are considered in acting on the applications are set forth in paragraph 7 of the Act (12 U.S.C. 1817(j)(7)).</P>
                <P>
                    The public portions of the applications listed below, as well as other related filings required by the Board, if any, are available for immediate inspection at the Federal Reserve Bank(s) indicated below and at the offices of the Board of Governors. This information may also be obtained on an expedited basis, upon request, by contacting the appropriate Federal Reserve Bank and from the Board's Freedom of Information Office at 
                    <E T="03">https://www.federalreserve.gov/foia/request.htm.</E>
                     Interested persons may express their views in writing on the standards enumerated in paragraph 7 of the Act.
                </P>
                <P>Comments regarding each of these applications must be received at the Reserve Bank indicated or the offices of the Board of Governors, Ann E. Misback, Secretary of the Board, 20th Street and Constitution Avenue NW, Washington DC 20551-0001, not later than February 22, 2024.</P>
                <P>
                    <E T="03">A. Federal Reserve Bank of San Francisco:</E>
                     (Joseph Cuenco, Assistant Vice President, Formations, Transactions &amp; Enforcement) 101 Market Street, San Francisco, California 94105-1579. Comments can also be sent electronically to: 
                    <E T="03">sf.fisc.comments.applications@sf.frb.org.</E>
                </P>
                <P>
                    1. 
                    <E T="03">The Stearns Living Trust, Glenn B. Stearns, as trustee, both of Newport Coast, California;</E>
                     to acquire voting shares of Infinity Bancorp, and thereby indirectly acquire voting shares of Infinity Bank, both of Santa Ana, California.
                </P>
                <P>Board of Governors of the Federal Reserve System.</P>
                <SIG>
                    <NAME>Erin Cayce,</NAME>
                    <TITLE>Assistant Secretary of the Board.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02523 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">GOVERNMENT ACCOUNTABILITY OFFICE</AGENCY>
                <SUBJECT>Government Auditing Standards—2024 Revision</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Government Accountability Office.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of document availability.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The U.S. Government Accountability Office (GAO) has issued its 2024 revision to Government Auditing Standards, known as the “Yellow Book.” To help ensure that the standards continue to meet the needs of the government auditing community, the Comptroller General of the United States established the Yellow Book Advisory Council to provide input on revisions to the Yellow Book. This 2024 revision of the standards includes the Advisory Council's input regarding the changes. It also includes input from public comments received on the 2023 exposure draft. The changes contained in the 2024 revision to Government Auditing Standards reflect major developments in the auditing, accountability, and financial management professions. The 2024 revision to Government Auditing Standards is available in electronic format for download from GAO's web page at www.gao.gov using GAO-24-106786 as a report number. It will also be available for sale in hardcopy from the Government Publishing Office in the near future at 
                        <E T="03">http://bookstore.gpo.gov</E>
                         or other GPO locations listed there. GAO-24-106786 may be used to find its GPO stock number and ISBN.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The 2024 revision will be effective December 15, 2025. Early implementation is permitted.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For information on Government Auditing Standards, please submit questions to James R. Dalkin, 
                        <E T="03">dalkinj@gao.gov</E>
                         or 202-512-3133.
                    </P>
                    <P>
                        <E T="03">Authority:</E>
                         Public Law 67-13, 42 Stat. 20 (June 10, 1921).
                    </P>
                    <SIG>
                        <NAME>James R. Dalkin,</NAME>
                        <TITLE>Director, Financial Management and Assurance, U.S. Government Accountability Office.</TITLE>
                    </SIG>
                </FURINF>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02594 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 1610-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Centers for Disease Control and Prevention</SUBAGY>
                <SUBJECT>Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to 5 U.S.C. 1009(d), notice is hereby given of the following meeting.</P>
                <P>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, and the Determination of the Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, CDC, pursuant to Public Law 92-463. 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.</P>
                <P>
                    <E T="03">Name of Committee: Disease, Disability, and Injury Prevention and Control Special Emphasis Panel (SEP)—DP24-081, Effectiveness of Telehealth-based Glaucoma Detection Program Among High-risk Population Within Community Health Settings.</E>
                </P>
                <P>
                    <E T="03">Date:</E>
                     April 11, 2024.
                </P>
                <P>
                    <E T="03">Time:</E>
                     10 a.m.-6 p.m., EDT.
                </P>
                <P>
                    <E T="03">Place:</E>
                     Teleconference/Web Conference.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     To review and evaluate grant applications.
                </P>
                <P>
                    <E T="03">For Further Information Contact:</E>
                     Catherine Barrett, Ph.D., Scientific Review Officer, National Center for Chronic Disease Prevention and Health Promotion, Centers for Disease Control and Prevention, 4770 Buford Highway, Mailstop S106-3, Atlanta, Georgia 30341-3717. Telephone: (404) 718-7664; Email: 
                    <E T="03">CBarrett@cdc.gov.</E>
                </P>
                <P>
                    The Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign 
                    <E T="04">Federal Register</E>
                     notices pertaining to announcements of meetings and other committee management activities, for both the Centers for Disease Control and Prevention and the Agency for Toxic Substances and Disease Registry.
                </P>
                <SIG>
                    <NAME>Kalwant Smagh,</NAME>
                    <TITLE>Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, Centers for Disease Control and Prevention.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02515 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4163-18-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8682"/>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Centers for Disease Control and Prevention</SUBAGY>
                <SUBJECT>Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to 5 U.S.C. 1009(d), notice is hereby given of the following meeting.</P>
                <P>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, and the Determination of the Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, CDC, pursuant to Public Law 92-463. 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.</P>
                <P>
                    <E T="03">Name of Committee: Disease, Disability, and Injury Prevention and Control Special Emphasis Panel (SEP)—DP24-031, Epidemiologic Cohort Study of Interstitial Cystitis.</E>
                </P>
                <P>
                    <E T="03">Date:</E>
                     April 10, 2024.
                </P>
                <P>
                    <E T="03">Time:</E>
                     10 a.m.-6 p.m., EDT.
                </P>
                <P>
                    <E T="03">Place:</E>
                     Teleconference/Web Conference.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     To review and evaluate grant applications.
                </P>
                <P>
                    <E T="03">For Further Information Contact:</E>
                     Catherine Barrett, Ph.D., Scientific Review Officer, National Center for Chronic Disease Prevention and Health Promotion, Centers for Disease Control and Prevention, 4770 Buford Highway, Mailstop S106-3, Atlanta, Georgia 30341-3717. Telephone: (404) 718-7664; Email: 
                    <E T="03">CBarrett@cdc.gov.</E>
                </P>
                <P>
                    The Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign 
                    <E T="04">Federal Register</E>
                     notices pertaining to announcements of meetings and other committee management activities, for both the Centers for Disease Control and Prevention and the Agency for Toxic Substances and Disease Registry.
                </P>
                <SIG>
                    <NAME>Kalwant Smagh,</NAME>
                    <TITLE>Director, Office of Strategic Business Initiatives, Office of the Chief Operating Officer, Centers for Disease Control and Prevention.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02514 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4163-18-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket Nos. FDA-2023-N-2894; FDA-2023-N-1929; FDA-2017-N-5569; FDA-2023-N-2564; FDA-2023-N-2851; FDA-2023-N-1554]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Announcement of Office of Management and Budget Approvals</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA) is publishing a list of information collections that have been approved by the Office of Management and Budget (OMB) under the Paperwork Reduction Act of 1995.</P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Amber Sanford, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 301-796-8867, 
                        <E T="03">PRAStaff@fda.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The following is a list of FDA information collections recently approved by OMB under section 3507 of the Paperwork Reduction Act of 1995 (44 U.S.C. 3507). The OMB control number and expiration date of OMB approval for each information collection are shown in table 1. Copies of the supporting statements for the information collections are available on the internet at 
                    <E T="03">https://www.reginfo.gov/public/do/PRAMain.</E>
                     An Agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.
                </P>
                <GPOTABLE COLS="3" OPTS="L2,nj,i1" CDEF="s100,14,14">
                    <TTITLE>Table 1—List of Information Collections Approved by OMB</TTITLE>
                    <BOXHD>
                        <CHED H="1">Title of collection</CHED>
                        <CHED H="1">OMB control No.</CHED>
                        <CHED H="1">
                            Date approval
                            <LI>expires</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Good Laboratory Practice (GLP) Regulations for Nonclinical Laboratory Studies</ENT>
                        <ENT>0910-0119</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Orphan Drugs</ENT>
                        <ENT>0910-0167</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Medical Devices; Device Tracking</ENT>
                        <ENT>0910-0442</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Channels of Trade Policy for Commodities with Residues of Pesticide Chemicals for Which Tolerances Have Been Revoked, Suspended, or Modified by the EPA</ENT>
                        <ENT>0910-0562</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Time and Extent Applications for Nonprescription Drug Products</ENT>
                        <ENT>0910-0688</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Qualitative Feedback on Food and Drug Administration Service Delivery</ENT>
                        <ENT>0910-0697</ENT>
                        <ENT>1/31/2027</ENT>
                    </ROW>
                </GPOTABLE>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02579 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4164-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8683"/>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2022-N-0105]</DEPDOC>
                <SUBJECT>International Drug Scheduling; Convention on Psychotropic Substances; Single Convention on Narcotic Drugs; World Health Organization; Scheduling Recommendations; Butonitazene; 3-Chloromethcathinone; Dipentylone; 2-Fluorodeschloroketamine; Bromazolam; Request for Comments</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA) is providing interested persons with the opportunity to submit written comments concerning recommendations by the World Health Organization (WHO) to impose international manufacturing and distributing restrictions, under international treaties, on certain drug substances. The comments received in response to this notice will be considered in preparing the United States' position on these proposals for a meeting of the United Nations Commission on Narcotic Drugs (CND) in Vienna, Austria, in March 2024. This notice is issued under the Controlled Substances Act (CSA).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit either electronic or written comments by February 27, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        You may submit comments as follows. Please note that late, untimely filed comments will not be considered. Electronic comments must be submitted on or before February 27, 2024. The 
                        <E T="03">https://www.regulations.gov</E>
                         electronic filing system will accept comments until 11:59 p.m. Eastern Time at the end of February 27, 2024. Comments received by mail/hand delivery/courier (for written/paper submissions) will be considered timely if they are received on or before that date.
                    </P>
                </ADD>
                <HD SOURCE="HD2">Electronic Submissions</HD>
                <P>Submit electronic comments in the following way:</P>
                <P>
                    • 
                    <E T="03">Federal eRulemaking Portal: https://www.regulations.gov.</E>
                     Follow the instructions for submitting comments. Comments submitted electronically, including attachments, to 
                    <E T="03">https://www.regulations.gov</E>
                     will be posted to the docket unchanged. Because your comment will be made public, you are solely responsible for ensuring that your comment does not include any confidential information that you or a third party may not wish to be posted, such as medical information, your or anyone else's Social Security number, or confidential business information, such as a manufacturing process. Please note that if you include your name, contact information, or other information that identifies you in the body of your comments, that information will be posted on 
                    <E T="03">https://www.regulations.gov.</E>
                </P>
                <P>• If you want to submit a comment with confidential information that you do not wish to be made available to the public, submit the comment as a written/paper submission and in the manner detailed (see “Written/Paper Submissions” and “Instructions”).</P>
                <HD SOURCE="HD2">Written/Paper Submissions</HD>
                <P>Submit written/paper submissions as follows:</P>
                <P>
                    • 
                    <E T="03">Mail/Hand Delivery/Courier (for written/paper submissions):</E>
                     Dockets Management Staff (HFA-305), Food and Drug Administration, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852.
                </P>
                <P>• For written/paper comments submitted to the Dockets Management Staff, FDA will post your comment, as well as any attachments, except for information submitted, marked and identified, as confidential, if submitted as detailed in “Instructions.”</P>
                <P>
                    <E T="03">Instructions:</E>
                     All submissions received must include the Docket No. FDA-2022-N-0105 for “International Drug Scheduling; Convention on Psychotropic Substances; Single Convention on Narcotic Drugs; World Health Organization; Scheduling Recommendations; Butonitazene; 3-Chloromethcathinone; Dipentylone; 2-Fluorodeschloroketamine; Bromazolam; Request for Comments.” Received comments, those filed in a timely manner (see 
                    <E T="02">ADDRESSES</E>
                    ), will be placed in the docket and, except for those submitted as “Confidential Submissions,” publicly viewable at 
                    <E T="03">https://www.regulations.gov</E>
                     or at the Dockets Management Staff between 9 a.m. and 4 p.m., Monday through Friday, 240-402-7500.
                </P>
                <P>
                    • Confidential Submissions—To submit a comment with confidential information that you do not wish to be made publicly available, submit your comments only as a written/paper submission. You should submit two copies total. One copy will include the information you claim to be confidential with a heading or cover note that states “THIS DOCUMENT CONTAINS CONFIDENTIAL INFORMATION.” The Agency will review this copy, including the claimed confidential information, in its consideration of comments. The second copy, which will have the claimed confidential information redacted/blacked out, will be available for public viewing and posted on 
                    <E T="03">https://www.regulations.gov.</E>
                     Submit both copies to the Dockets Management Staff. If you do not wish your name and contact information to be made publicly available, you can provide this information on the cover sheet and not in the body of your comments and you must identify this information as “confidential.” Any information marked as “confidential” will not be disclosed except in accordance with 21 CFR 10.20 and other applicable disclosure law. For more information about FDA's posting of comments to public dockets, see 80 FR 56469, September 18, 2015, or access the information at: 
                    <E T="03">https://www.govinfo.gov/content/pkg/FR-2015-09-18/pdf/2015-23389.pdf.</E>
                </P>
                <P>
                    <E T="03">Docket:</E>
                     For access to the docket to read background documents or the electronic and written/paper comments received, go to 
                    <E T="03">https://www.regulations.gov</E>
                     and insert the docket number, found in brackets in the heading of this document, into the “Search” box and follow the prompts and/or go to the Dockets Management Staff, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852, 240-402-7500.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Edward (Greg) Hawkins, Center for Drug Evaluation and Research, Controlled Substance Staff, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 51, Rm. 5110, Silver Spring, MD 20993-0002, 301-796-0727, 
                        <E T="03">Edward.hawkins@fda.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The United States is a party to the 1971 Convention on Psychotropic Substances (1971 Convention). Section 201(d)(2)(B) of the CSA (21 U.S.C. 811(d)(2)(B)) provides that when the United States is notified under Article 2 of the 1971 Convention that the CND proposes to decide whether to add a drug or other substance to one of the schedules of the 1971 Convention, transfer a drug or substance from one schedule to another, or delete it from the schedules, the Secretary of State must transmit notice of such information to the Secretary of Health and Human Services (Secretary of HHS). The Secretary of HHS must then publish a summary of such information in the 
                    <E T="04">Federal Register</E>
                     and provide opportunity for interested persons to submit comments. The Secretary of HHS must then evaluate the proposal and furnish a recommendation to the Secretary of State that shall be binding on the representative of the United 
                    <PRTPAGE P="8684"/>
                    States in discussions and negotiations relating to the proposal.
                </P>
                <P>
                    As detailed in the following paragraphs, the Secretary of State has received notification from the Secretary-General of the United Nations (the Secretary-General) regarding four substances to be considered for control under the 1971 Convention. This notification reflects the recommendation from the 46th WHO Expert Committee for Drug Dependence (ECDD), which met in October 2023. In the 
                    <E T="04">Federal Register</E>
                     of August 24, 2023 (88 FR 52179), FDA announced the WHO ECDD review and invited interested persons to submit information for WHO's consideration.
                </P>
                <P>
                    The full text of the notification from the Secretary-General is provided in section II of this document. Section 201(d)(2)(B) of the CSA requires the Secretary of HHS, after receiving a notification proposing scheduling, to publish a notice in the 
                    <E T="04">Federal Register</E>
                     to provide the opportunity for interested persons to submit information and comments on the proposed scheduling action.
                </P>
                <P>
                    The United States is also a party to the 1961 Single Convention on Narcotic Drugs (1961 Convention). The Secretary of State has received a notification from the Secretary-General regarding one substance to be considered for control under this convention. The CSA does not require HHS to publish a summary of such information in the 
                    <E T="04">Federal Register</E>
                    . Nevertheless, to provide interested and affected persons an opportunity to submit comments regarding the WHO recommendations for drugs under the 1961 Convention, the notification regarding these substances is also included in this 
                    <E T="04">Federal Register</E>
                     notice. The comments will be shared with other relevant Agencies to assist the Secretary of State in formulating the position of the United States on the control of these substances. The HHS recommendations are not binding on the representative of the United States in discussions and negotiations relating to the proposal regarding control of substances under the 1961 Convention.
                </P>
                <HD SOURCE="HD1">II. United Nations Notification</HD>
                <P>The formal notification from the United Nations that identifies the drug substances and explains the basis for the scheduling recommendations is reproduced as follows (non-relevant text removed):</P>
                <EXTRACT>
                    <P>
                        <E T="03">Reference:</E>
                    </P>
                    <FP SOURCE="FP-1">NAR/CL.18/2023</FP>
                    <FP SOURCE="FP-1">WHO/ECDD46; 1961C-Art.3, 1971C-Art.2</FP>
                    <FP SOURCE="FP-1">CU 2023/403/DTA/SGB</FP>
                    <P>The Secretariat of the United Nations presents its compliments to the Permanent Mission of the United States of America to the United Nations (Vienna) and has the honour to inform the Permanent Mission that, in a letter dated 15 November 2023, the Director-General of the World Health Organization (WHO), pursuant to article 3, paragraphs 1 and 3 of the Single Convention on Narcotic Drugs of 1961 as amended by the 1972 Protocol (1961 Convention), and article 2, paragraphs 1 and 4 of the Convention on Psychotropic Substances of 1971 (1971 Convention), notified the Secretary-General of the following recommendations of the Forty-sixth Meeting of the WHO's Expert Committee on Drug Dependence (ECDD):</P>
                    <P>
                        <E T="03">Substance recommended to be added to Schedule I of the 1961 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—Butonitazene</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC (International Union of Pure and Applied Chemistry) name:</E>
                         N,N-diethyl-2-[(4-butoxyphenyl)methyl]-5-nitro-1H-benzimidazole-1-ethanamine
                    </FP>
                    <P>
                        <E T="03">Substances recommended to be added to Schedule II of the 1971 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—3-chloromethcathinone or 3-CMC</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         1-(3-chlorophenyl)-2-(methylamino)propan-1-one
                    </FP>
                    <FP SOURCE="FP-1">—Dipentylone</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         1-(1,3-benzodioxol-5-yl)-2-(dimethylamino)pentan-1-one
                    </FP>
                    <FP SOURCE="FP-1">—2-fluorodeschloroketamine</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         2-(2-fluorophenyl)-2-(methylamino)cyclohexan-1-one
                    </FP>
                    <P>
                        <E T="03">Substance recommended to be added to Schedule IV of the 1971 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—Bromazolam</FP>
                    <P>
                        <E T="03">IUPAC name:</E>
                         8-bromo-1-methyl-6-phenyl-4H-[1,2,4]triazolo[4,3-a][1,4]benzodiazepine
                    </P>
                    <P>
                        <E T="03">Substance recommended to proceed to critical review at a future ECDD meeting:</E>
                    </P>
                    <P>In the letter from the Director-General of WHO to the Secretary-General, reference is also made to the recommendation made by the WHO Expert Committee on Drug Dependence (ECDD), at its forty-sixth meeting, to conduct a critical review of the following substance:</P>
                    <FP SOURCE="FP-1">—Carisoprodol</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         2-[(carbamoyloxy)methyl]-2-methylpentyl(1-methylethyl)carbamate
                    </FP>
                    <P>
                        <E T="03">Substances to be kept under surveillance:</E>
                    </P>
                    <P>In the letter from the Director-General of WHO to the Secretary-General, reference is also made to the recommendation made by the WHO Expert Committee on Drug Dependence (ECDD), at its forty-sixth meeting, to keep the following substances under surveillance:</P>
                    <FP SOURCE="FP-1">—Flubromazepam</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         7-bromo-5-(2-fluorophenyl)-1,3-dihydro-2H-1,4-benzodiazepin-2-one
                    </FP>
                    <FP SOURCE="FP-1">—Nitrous oxide</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         nitrous oxide
                    </FP>
                    <P>In accordance with the provisions of article 3, paragraph 2, of the 1961 Convention and article 2, paragraph 2, of the 1971 Convention, the notification is hereby transmitted as NAR/CL.18/2023—Annex I to the present note. In connection with the notification, WHO also submitted a summary of the assessments and findings for these recommendations made by ECDD in Annex 1 to the letter to the Secretary-General, hereby transmitted in NAR/CL.18/2023—Annex II.</P>
                    <P>
                        Also, in accordance with the same provisions, the notification from WHO will be brought to the attention of the sixty-seventh session of the Commission on Narcotic Drugs (14-22 March 2024) in a pre-session document that will be made available in the six official languages of the United Nations on the website of the sixty-seventh session of the Commission on Narcotic Drugs: 
                        <E T="03">https://www.unodc.org/unodc/en/commissions/CND/session/67_Session_2024/67CND_Main.html.</E>
                    </P>
                    <P>In order to assist the Commission in reaching a decision, it would be appreciated if the Permanent Mission could communicate any comments it considers relevant to the possible scheduling of substances recommended by WHO to be placed under international control under the 1961 Convention, namely:</P>
                    <FP SOURCE="FP-1">—Butonitazene</FP>
                    <FP>as well as any economic, social, legal, administrative or other factors that it considers relevant to the possible scheduling of substances recommended by WHO to be placed under international control under the 1971 Convention, namely:</FP>
                    <FP SOURCE="FP-1">—3-chloromethcathinone or 3-CMC</FP>
                    <FP SOURCE="FP-1">—Dipentylone</FP>
                    <FP SOURCE="FP-1">—2-fluorodeschloroketamine</FP>
                    <FP SOURCE="FP-1">—Bromazolam</FP>
                    <P>The Secretariat of the United Nations avails itself of this opportunity to renew to the Permanent Mission of the United States of America to the United Nations (Vienna) the assurances of its highest consideration.</P>
                    <FP>12 December 2023</FP>
                    <HD SOURCE="HD1">Annex I</HD>
                    <HD SOURCE="HD2">Letter Addressed to the Secretary-General of the United Nations From the Director-General of the World Health Organization, Dated 15 November 2023</HD>
                    <P>I have the honour to refer to the Forty-sixth Meeting of the World Health Organization (WHO) Expert Committee on Drug Dependence (ECDD), which was convened in Geneva, Switzerland, from 16 to 19 October 2023.</P>
                    <P>WHO is mandated by the 1961 and 1971 International Drug Control Conventions to make recommendations to the Secretary-General of the United Nations on the need for a level of international control of psychoactive substances based on the advice of its independent scientific advisory body, the ECDD. To assess the appropriate control of a psychoactive substance, WHO convenes ECDD annually to review the potential of a substance to cause dependence, abuse and harm to health, as well as any therapeutic applications.</P>
                    <P>
                        The Forty-sixth WHO ECDD Meeting critically reviewed six new psychoactive substances: one novel synthetic opioid (butonitazene), two cathinones/stimulants (3-chloromethcathinone or 3-CMC, dipentylone), one dissociative substance (2-fluorodeschloroketamine) and two benzodiazepines (bromazolam, flubromazepam). These substances, with the exception of bromazolam, had previously not 
                        <PRTPAGE P="8685"/>
                        been formally reviewed by WHO, and are currently not under international control.
                    </P>
                    <P>Information was brought to WHO's attention that these substances are clandestinely manufactured, of risk to public health and society, and of no recognized therapeutic use by any party. Therefore, a critical review to consider international scheduling measures was undertaken for each substance so that the Expert Committee could consider whether information about these substances may justify the scheduling of a substance in the 1961 or 1971 Conventions.</P>
                    <P>In addition, the Forty-sixth ECDD carried out pre-reviews of the medications nitrous oxide and carisoprodol to consider whether current information justified a critical review.</P>
                    <P>With reference to Article 3, paragraphs 1 and 3 of the Single Convention on Narcotic Drugs (1961), as amended by the 1972 Protocol, and Article 2, paragraphs 1 and 4 of the Convention on Psychotropic Substances (1971), WHO is pleased to endorse and submit the following recommendations of the Forty-sixth Meeting of ECDD:</P>
                    <P>
                        <E T="03">Substance recommended to be added to Schedule I of the 1961 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—Butonitazene</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC (International Union of Pure and Applied Chemistry) name:</E>
                         N,N-diethyl-2-[(4-butoxyphenyl)methyl]-5-nitro-1H-benzimidazole-1-ethanamine
                    </FP>
                    <P>
                        <E T="03">Substances recommended to be added to Schedule II of the 1971 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—3-chloromethcathinone or 3-CMC</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         1-(3-chlorophenyl)-2-(methylamino)propan-1-one
                    </FP>
                    <FP SOURCE="FP-1">—Dipentylone</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         1-(1,3-benzodioxol-5-yl)-2-(dimethylamino)pentan-1-one
                    </FP>
                    <FP SOURCE="FP-1">—2-fluorodeschloroketamine</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         2-(2-fluorophenyl)-2-(methylamino)cyclohexan-1-one
                    </FP>
                    <P>
                        <E T="03">Substance recommended to be added to Schedule IV of the 1971 Convention:</E>
                    </P>
                    <FP SOURCE="FP-1">—Bromazolam</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         8-bromo-1-methyl-6-phenyl-4H-[1,2,4]triazolo[4,3-a][1,4]benzodiazepine
                    </FP>
                    <P>
                        <E T="03">Substance recommended to proceed to critical review at a future ECDD meeting:</E>
                    </P>
                    <FP SOURCE="FP-1">—Carisoprodol</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         2-[(carbamoyloxy)methyl]-2-methylpentyl(1-methylethyl)carbamate
                    </FP>
                    <P>
                        <E T="03">Substances to be kept under surveillance:</E>
                    </P>
                    <FP SOURCE="FP-1">—Flubromazepam</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         7-bromo-5-(2-fluorophenyl)-1,3-dihydro-2H-1,4-benzodiazepin-2-one
                    </FP>
                    <FP SOURCE="FP-1">—Nitrous oxide</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">IUPAC name:</E>
                         nitrous oxide
                    </FP>
                    <P>The assessments and findings on which these recommendations are based are set out in detail in the forty-sixth meeting report of the WHO Expert Committee on Drug Dependence. A summary of the assessment and recommendations made by the Forty-sixth ECDD is contained in Annex I to this letter.</P>
                    <P>I am pleased with the ongoing collaboration between WHO, the United Nations Office on Drugs and Crime, and the International Narcotics Control Board, and in particular, how this collaboration has benefited the work of the WHO Expert Committee on Drug Dependence and more generally, the implementation of the operational recommendations of the United Nations General Assembly Special Session 2016.</P>
                    <HD SOURCE="HD1">Annex II</HD>
                    <HD SOURCE="HD2">Summary Assessment and Recommendations of the 46th Expert Committee on Drug Dependence, 16-19 October 2023</HD>
                    <P>
                        <E T="03">Substance to be added to Schedule I of the Single Convention on Narcotic Drugs (1961):</E>
                    </P>
                    <HD SOURCE="HD3">Butonitazene</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>Butonitazene (IUPAC name: N,N-diethyl-2-[(4-butoxyphenyl)methyl]-5-nitro-1H-benzimidazole-1-ethanamine), also known as butoxynitazene, is a benzimidazole-derived synthetic opioid. Butonitazene is found as a crystalline solid and a white or yellow-brown powder.</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Butonitazene has not been reviewed formally by WHO and is not currently under international control. Information was brought to WHO's attention that this substance is manufactured clandestinely, poses a risk to public health, and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>The chemical structure and pharmacological effects of butonitazene are similar to those of opioid drugs such as etonitazene and isotonitazene that are controlled under Schedule I of the United Nations Conventions on Narcotic Drugs of 1961. Butonitazene is an agonist at μ-opioid receptors and has similar analgesic effects as morphine and fentanyl.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No studies in experimental animal or humans were found on the dependence potential of butonitazene; however, as it is a μ-opioid receptor agonist, it would be expected to produce dependence.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>No studies on the abuse potential of butonitazene in humans were found. In an animal model predictive of abuse potential, butonitazene had morphine-like effects, which were blocked by the opioid antagonist naltrexone. As it is a μ-opioid receptor agonist, it would be expected to produce euphoria and other effects predictive of high abuse liability. Butonitazene is reported to be administered by various routes, including smoking, intranasally and by injection. Non-fatal intoxications that involved butonitazene and required hospitalization have been reported. Seizures of butonitazene have been reported in multiple countries in two regions.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Butonitazene is not known to have any therapeutic use and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>Butonitazene, also known as butoxynitazene, is a synthetic opioid that is liable to abuse and to production of ill effects similar to those of other opioids that are controlled under Schedule I of the Single Convention on Narcotic Drugs, 1961. Its use has been reported in a number of countries. It has no known therapeutic use and is likely to cause substantial harm. The Committee recommended that butonitazene (IUPAC name: N,N-diethyl-2-[(4-butoxyphenyl)methyl]-5-nitro-1H-benzimidazole-1-ethanamine), also known as butoxynitazene, be added to Schedule I of the Single Convention on Narcotic Drugs, 1961.</P>
                    <P>
                        <E T="03">Substances to be added to Schedule II of the Convention on Psychotropic Substance (1971):</E>
                    </P>
                    <HD SOURCE="HD3">3-Chloromethcathinone (3-CMC)</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>3-Chloromethcathinone or 3-CMC (IUPAC name: 1-(3-chlorophenyl)-2-(methylamino)propan-1- one), is a synthetic cathinone. 3-CMC has been described as a grey or white solid and as a white powder. It has been identified in capsule, tablet, and liquid forms.</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>3-CMC has not been reviewed formally by WHO and is not currently under international control. Information was brought to WHO's attention that this substance is manufactured clandestinely, poses a risk to public health and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>3-CMC is a chemical analogue of methcathinone, which is controlled under Schedule I of the United Nations Convention on Psychotropic Substances of 1971. Its structural isomer, 4-CMC, is controlled under Schedule II of the United Nations Convention on Psychotropic Substances of 1971. In common with other cathinone psychostimulants, 3-CMC has been shown to act via dopamine, serotonin and norepinephrine transporters in the central nervous system to increase the concentrations of these neurotransmitters.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No controlled experimental studies of the dependence potential of 3-CMC in experimental animals or humans were available; however, clinical admissions associated with dependence to 3-CMC have been reported. Given its action in the central nervous system, 3-CMC would be expected to produce a state of dependence similar to that produced by amphetamine and other psychostimulants.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>
                        No controlled studies of the abuse potential of 3-CMC in experimental animals or humans were available. In experimental animals, 3-CMC produced locomotor effects consistent with a psychostimulant. Cases of intoxication with 3-CMC alone and with other drugs requiring hospitalization have been reported. The adverse effects included 
                        <PRTPAGE P="8686"/>
                        agitation, restlessness, seizures, high blood pressure, sweating, and chest pain. These adverse effects are similar to those of other psychostimulants, such as amphetamine and various cathinones. Fatal intoxications involving 3-CMC have been documented, including in cases in which 3-CMC was the only substance identified. It is reported to be administered by various routes, including smoking, intranasally and by injection. 3-CMC has been detected in an increasing number of countries in most regions of the world. Seizures of 3-CMC have been reported in multiple countries and regions, with recent increases coinciding with international control of 4-CMC.
                    </P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>3-CMC is not known to have any therapeutic uses and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>3-Chloromethcathinone or 3-CMC is a synthetic cathinone with effects similar to those of other synthetic cathinones, such as mephedrone and 4-CMC, which are listed as Schedule II substances under the Convention on Psychotropic Substances of 1971. Its mode of action and effects are similar to those of other cathinones. There is evidence of use of 3-CMC in a number of countries and regions, where it has resulted in fatal and non-fatal intoxications. The substance causes substantial harm, constitutes a substantial risk to public health and has no therapeutic use. The Committee recommended that 3-chloromethcathinone or 3-CMC (IUPAC name: 1(3-chlorophenyl)-2-(methylamino)propan-1-one) be added to Schedule II of the Convention on Psychotropic Substances of 1971.</P>
                    <HD SOURCE="HD3">Dipentylone</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>Dipentylone or N-methylpentylone (IUPAC name: 1-(1,3-benzodioxol-5-yl)-2-(dimethylamino)pentan-1-one, also known as N,N-dimethylpentylone, dimethylpentylone or bk-DMBDP) is a synthetic cathinone. It is distributed mainly as crystals or tablets.</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Dipentylone has not been reviewed formally by WHO and is not currently under international control. Information was brought to WHO's attention that this substance is manufactured clandestinely, poses a risk to public health and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>In common with other cathinone psychostimulants, dipentylone has been shown to act via dopamine, serotonin, and norepinephrine transporters in the central nervous system to increase the concentrations of these neurotransmitters. Online self-reports describe insomnia, hallucinations, paranoia and confusion after its use. Adverse effects documented in clinical presentations include agitation and tachycardia. These effects are consistent with a psychostimulant mechanism of action.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No controlled experimental studies of the dependence potential of dipentylone in experimental animals or humans were available. In view of its action in the central nervous system, however, dipentylone would be expected to produce a state of dependence similar to that produced by amphetamine and other psychostimulants.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>Studies in experimental animals demonstrate that dipentylone has an abuse potential similar to that of methamphetamine, which is listed under Schedule II of the Convention on Psychotropic Substances of 1971, and cocaine, which is listed under Schedule I of the Convention on Narcotic Drugs of 1961. Dipentylone has been shown to produce locomotor stimulant effects in animal models. No controlled studies on the abuse potential of dipentylone in humans were identified. Non-fatal intoxication involving dipentylone that required hospitalization has been reported, and fatal intoxications have been reported by a number of countries, in which no other substance was involved in at least one case. Cases of driving under the influence of dipentylone have reported by some countries. Seizures of dipentylone have been reported in a number of countries and regions. Dipentylone appears to be commonly sold as cocaine or MDMA.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Dipentylone is not known to have any therapeutic uses and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>Dipentylone or N-methylpentylone is a synthetic cathinone with effects similar to those of other synthetic cathinones and other psychostimulants, such as methamphetamine that are listed under Schedule II of the Convention on Psychotropic Substances of 1971. Its mode of action suggests the likelihood of abuse, and it poses a substantial risk to public health. It has no known therapeutic use. The Committee recommended that dipentylone or N-methylpentylone (IUPAC name: 1-(1,3- benzodioxol-5-yl)-2-(dimethylamino)pentan-1-one) be added to Schedule II of the Convention on Psychotropic Substances of 1971.</P>
                    <HD SOURCE="HD3">2-Fluorodeschloroketamine</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>2-Fluorodeschloroketamine (IUPAC name: 2-(2-fluorophenyl)-2-(methylamino)cyclohexan-1-one) is an arylcyclohexylamine that is chemically related to the dissociative anaesthetic ketamine. It has been described as a brown oil in its free base form or as a crystalline solid or white powder as a salt. It has been identified in some food products (chocolates).</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>2-Fluorodeschloroketamine has not been reviewed formally by WHO and is not currently under international control. Information was brought to WHO's attention that this substance is manufactured clandestinely, poses a risk to public health and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>The mechanism of action of 2-fluorodeschloroketamine is uncertain, but it has effects similar to those of N-methyl-D-aspartate receptor antagonists such as phencyclidine, which are controlled under Schedule II of the Convention on Psychotropic Substances of 1971. Effects documented during clinical admissions due to 2-fluorodeschloroketamine intoxication include dissociation, confusion, agitation, tachycardia and hypertension. Unverified reports from people who use 2-fluorodeschloroketamine describe hallucinogenic and dissociative effects. The clinical and self-reported effects of 2-fluorodeschloroketamine are consistent with the effects of phencyclidine.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No controlled studies in experimental animal or humans were found on the dependence potential of 2-fluorodeschloroketamine; however, clinical admissions for dependence on 2-fluorodeschloroketamine have been reported in various countries and regions.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>Studies in experimental animals indicate that 2-fluorodeschloroketamine has behavioural (locomotor) effects consistent with central nervous system stimulation. Such studies confirm that it has rewarding properties and effects predictive of abuse liability. Cases of intoxication that involved 2-fluorodeschloroketamine and required hospitalization have been reported. The adverse effects included central nervous system effects such as dissociation, confusion, agitation, combativeness, nystagmus, hallucinations and impaired consciousness, loss of consciousness and cardiovascular effects such as tachycardia and hypertension. Fatal intoxications involving 2-fluorodeschloroketamine have been documented, including at least one case in which no other substance was involved. 2-Fluorodeschloroketamine has been analytically confirmed in people driving under the influence of drugs and in clinical admissions due to drug intoxication. It is reported to be administered by various routes including orally, intranasally and by injection. Seizures have been reported in a number of countries in several regions.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>2-Fluorodeschloroketamine is not known to have any therapeutic use, is not listed on the WHO Model Lists of Essential Medicines and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>
                        2-Fluorodeschloroketamine has effects similar to those of dissociative substances such as phencyclidine, which are controlled under Schedule II of the Convention on Psychotropic Substances of 1971. The results of studies in experimental animals indicate a high likelihood of abuse. There is evidence 
                        <PRTPAGE P="8687"/>
                        that this substance is used in a number of countries in several regions. 2-Fluorodeschloroketamine causes substantial harm, including impaired driving, emergency department presentations and deaths. It has no known therapeutic use. The Committee recommended that 2-fluorodeschloroketamine (IUPAC name: 2-(2-fluorophenyl)-2-(methylamino)cyclohexan-1-one) be added to Schedule II of the Convention on Psychotropic Substances of 1971.
                    </P>
                    <P>
                        <E T="03">Substance to be added to Schedule IV of the Convention on Psychotropic Substances (1971):</E>
                    </P>
                    <HD SOURCE="HD3">Bromazolam</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>Bromazolam (IUPAC name: 8-bromo-1-methyl-6-phenyl-4H-[1,2,4]triazolo[4,3-a][1,4]benzodiazepine) is a triazolobenzodiazepine. Bromazolam has been described as a white or crystalline solid and has been identified in tablets, capsules, powders, solutions and chewable candy products (“gummies”). Bromazolam has been identified in falsified pharmaceutical benzodiazepine products.</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Bromazolam was critically reviewed at the 45th ECDD meeting. Because of lack of information on its pharmacological effects, it was not recommended for international control but was placed under surveillance. New information on such effects was brought to WHO's attention, in addition to ongoing evidence that this substance is manufactured clandestinely, poses a risk to public health and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>
                        Bromazolam is a benzodiazepine with relatively high potency and a short-intermediate duration of action. It is structurally related to alprazolam. Like other benzodiazepines, bromazolam binds to γ-aminobutyric acid (GABA
                        <E T="52">A</E>
                        ) receptors, and its effects can be reversed by administration of the benzodiazepine receptor antagonist flumazenil. Unconfirmed online reports by people who use bromazolam describe benzodiazepine-like effects, including hypnotic, sedative, muscle relaxant and euphoric effects.
                    </P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No controlled studies in experimental animals or in humans have examined the dependence potential of bromazolam. In view of its pharmacological effects and similarity to other benzodiazepines, however, it would be expected to produce dependence. Online self-reports describe withdrawal symptoms after cessation of chronic use.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>No studies in humans were found of the abuse liability of bromazolam. In an animal model predictive of abuse liability, bromazolam had effects similar to those of midazolam and diazepam, which are controlled under Schedule IV of the Convention on Psychotropic Substances of 1971. The effects were attenuated by pre-administration of the benzodiazepine receptor antagonist flumazenil, confirming bromazolam's action as a benzodiazepine. Seizures of bromazolam have been reported increasingly in many countries in various regions. Bromazolam has been analytically confirmed as a causal or contributory agent in several deaths and non-fatal intoxications, and its presence has been confirmed in instances of driving under the influence of drugs. These harms have been reported in multiple countries and regions.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Bromazolam is not known to have any therapeutic use, is not listed on the WHO Model Lists of Essential Medicines and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>The mechanism of action and ill effects of bromazolam are similar to those of other benzodiazepines, such as alprazolam and diazepam, that are listed under Schedule IV of the Convention on Psychotropic Substances of 1971. Reports of seizures and detection in fatal and non-fatal intoxications have increased over time. There is sufficient evidence of its abuse to conclude that it constitutes a significant risk to public health and has no known therapeutic use. The Committee recommended that bromazolam (IUPAC name: 8-bromo-1-methyl-6-phenyl-4H-[1,2,4]triazolo[4,3-a][1,4]benzodiazepine) be added to Schedule IV of the Convention on Psychotropic Substances of 1971.</P>
                    <P>
                        <E T="03">Substances to be recommended for critical review:</E>
                    </P>
                    <HD SOURCE="HD3">Carisoprodol</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>Carisoprodol (IUPAC name: 2-[(carbamoyloxy)methyl]-2-methylpentyl(1-ethylethyl)carbamate) is a centrally-acting skeletal muscle relaxant sold as a single-ingredient preparation and in combination products. Carisoprodol is available as a pharmaceutical product in tablet form, has been detected in falsified pharmaceuticals and is also found as a white powder.</P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Carisoprodol was pre-reviewed at the 32nd ECDD meeting in 2000. The Committee did not recommend critical review of carisoprodol at that time, noting that sporadic nonmedical use of carisoprodol was not a new phenomenon and there was no indication of significantly increasing nonmedical use. A new pre-review was initiated in 2023 after information received from an international agency that suggested a significant increase in the reported number of trafficking cases and seizures involving carisoprodol.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>
                        Carisoprodol is an analogue of meprobamate and has effects similar to those of other central nervous system depressants such as meprobamate, pentobarbital, diazepam and chlordiazepoxide that are listed under schedules III and IV of the Convention on Psychotropic Substances of 1971. Meprobamate is also a metabolite of carisoprodol. Although its exact mechanism of action is not known, the therapeutic effects of carisoprodol appear to be due to modulation of GABA
                        <E T="52">A</E>
                         receptors similar to the action of barbiturates. The sedative effects of carisoprodol can be potentiated when it is combined with benzodiazepines, opioids or alcohol.
                    </P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>Tolerance and withdrawal have been documented in experimental animals, and the potential for dependence on carisoprodol is considered to be similar to that of barbiturates and benzodiazepines. Tolerance, withdrawal and craving have been documented in humans, and increasing numbers of cases of carisoprodol dependence have been documented in pharmacovigilance reporting systems.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>In animal models indicative of abuse liability, the effects of carisoprodol were similar to those of pentobarbital, chlordiazepoxide and meprobamate in a dose-dependent manner. In humans, carisoprodol produces central nervous system depressant effects, including drowsiness, sedation, confusion and coma. Public health harm associated with use of carisoprodol has included cases of driving under the influence of the drug. Nonmedical use of carisoprodol is widely documented in multiple countries and regions, including in combination with opioids and/or benzodiazepines. The incidence of poisoning and other public health harm has been reported to have decreased in some countries after increased restrictions on carisoprodol prescription or removal of the drug from the market.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Carisoprodol is a centrally acting muscle relaxant used in some countries in the short term as an adjunct in symptomatic treatment of acute musculoskeletal disorders associated with painful muscle spasms. It is not on the 2023 WHO Essential Medicines List or the WHO Essential Medicines List for Children. It has been withdrawn from use in some countries because of concern about increased rates of diversion, nonmedical use, dependence, intoxication and psychomotor impairment.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>The increasing evidence of misuse and abuse of carisoprodol in a number of countries is a growing cause for concern. Carisoprodol has been shown to produce a state of dependence and central nervous system depression. It has only limited medical use. The Committee recommended that carisoprodol be subject to a future critical review.</P>
                    <P>
                        <E T="03">Substances to be kept under surveillance:</E>
                    </P>
                    <HD SOURCE="HD3">Flubromazepam</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>
                        Flubromazepam (IUPAC name: 7-bromo-5-(2-fluorophenyl)-1,3-dihydro-2H-1,4-benzodiazepin-2-one) is a 1,4-benzodiazepine. Flubromazepam is described as a white powder or a crystalline solid and has been found in infused paper forms.
                        <PRTPAGE P="8688"/>
                    </P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Flubromazepam has not been formally reviewed by WHO and is not currently under international control. Information was brought to WHO's attention that this substance is manufactured clandestinely, poses a risk to public health and has no recognized therapeutic use.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>The chemical structure of flubromazepam is similar to that of other benzodiazepines, including phenazepam. Currently, there is insufficient information on the pharmacological profile of flubromazepam from controlled studies in experimental animals or humans to conclude that it has effects that are similar to those of benzodiazepines that are controlled under the Convention on Psychotropic Substances of 1971. Online self-reports by people who claim to have used flubromazepam describe sedative, muscle relaxant and euphoric effects and its use to self-manage benzodiazepine withdrawal. There are, however, no clinical reports to confirm such effects.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>No controlled study in experimental animals or humans have addressed the dependence potential of flubromazepam.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>No studies in humans were found of the abuse liability of flubromazepam. People who self-report flubromazepam use describe euphoric effects and other benzodiazepine-like effects that would suggest it has a similar likelihood of abuse, but their use of flubromazepam cannot be confirmed. Results from limited studies in experimental animals suggest abuse liability. Seizures have been reported in multiple countries across a number of regions. Although flubromazepam has been detected in several deaths and cases of driving under the influence of drugs, other drugs were also detected, and the contribution of flubromazepam was unclear.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Flubromazepam is not known to have any therapeutic use, is not listed on the WHO Model Lists of Essential Medicines and has never been marketed as a medicinal product.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>Flubromazepam is a 1,4-benzodiazepine. Although it is chemically similar to other benzodiazepines listed under Schedule IV of the Convention on Psychotropic Substances of 1971, little information is available on its effects. Few studies in experimental animals and no studies in humans were found on its effects or abuse potential. The limited information on its effects provides insufficient evidence to justify the placement of flubromazepam under international control. The Committee recommended that flubromazepam (IUPAC name: 7-bromo-5-(2-fluorophenyl)-1,3-dihydro-2H-1,4-benzodiazepin-2-one) be kept under surveillance by the WHO ECDD secretariat.</P>
                    <HD SOURCE="HD3">Nitrous Oxide</HD>
                    <HD SOURCE="HD3">Substance Identification</HD>
                    <P>
                        Nitrous oxide (IUPAC name: Nitrous oxide, N
                        <E T="52">2</E>
                        O) is an inhalational anaesthetic marketed under a range of trade names as both a single ingredient gas and in multi-ingredient preparations. It is also manufactured for industrial use, including in food production, as small metal canisters, bulbs and larger cylinders. It is described as a colourless gas.
                    </P>
                    <HD SOURCE="HD3">WHO Review History</HD>
                    <P>Nitrous oxide is not currently under international control and has never been reviewed by the ECDD. Information was brought to WHO's attention by a Member State of increased nonmedical use, such that it presented a risk to public health.</P>
                    <HD SOURCE="HD3">Similarity to Known Substances and Effects on the Central Nervous System</HD>
                    <P>Nitrous oxide appears to have multiple mechanisms of action that are not entirely understood. There is some evidence for effects on opioid, GABAergic, glutamatergic and other neurotransmitter systems. Nitrous oxide produces anaesthesia, analgesia and, in laboratory studies with humans, subjective effects such as perceptual distortion, paranoia, delusions, anhedonia and cognitive disorganization.</P>
                    <HD SOURCE="HD3">Dependence Potential</HD>
                    <P>Acute and chronic tolerance to the effects of nitrous oxide have been documented in experimental animals, with signs of withdrawal when exposure was ended abruptly. Animals that were tolerant to nitrous oxide were partially cross-tolerant to ethanol but not to barbiturates or morphine. Laboratory studies in humans provide evidence of tolerance to some effects of nitrous oxide, but the degree of tolerance varied according to the effect and between individuals. Epidemiological and clinical studies provide evidence of dependence.</P>
                    <HD SOURCE="HD3">Actual Abuse and/or Evidence of Likelihood of Abuse</HD>
                    <P>The evidence from studies in experimental animals on the likelihood of abuse of nitrous oxide is inconsistent. The abuse potential of nitrous oxide has been reported since the 19th century, including its euphoric effects and ability to cause auditory and visual distortions. Nitrous oxide was originally promoted for recreational use as “laughing gas”; however, laboratory studies with humans have produced inconsistent results on abuse liability. The global prevalence of non-medical use of nitrous oxide is unknown. Reports from several countries indicate that nonmedical use is highest among adolescents and young adults, and evidence from some countries indicates an increase in use in recent years. Nitrous oxide used nonmedically is typically obtained from legal manufacturers, with no evidence of illicit manufacture and minimal evidence of cross-border trading. Nitrous oxide use has been implicated in cases of impaired driving. Deaths directly related to nonmedical use of nitrous oxide appear to be rare and to be due to intended or unintended asphyxia. Long-term exposure can result in neurological and haematological toxicity.</P>
                    <HD SOURCE="HD3">Therapeutic Use</HD>
                    <P>Nitrous oxide is widely used globally for analgesia and sedation during childbirth and in painful short procedures in dentistry and emergency medicine. It is used commonly as a supplementary agent in anaesthesia. Nitrous oxide is listed on the 2023 WHO Model List of Essential Medicines and the Essential Medicines List for Children as an inhalational anaesthetic. Clinical trials of nitrous oxide are being conducted to explore its value as a medication for other indications such as treatment-resistant depression and management of alcohol withdrawal symptoms.</P>
                    <HD SOURCE="HD3">Rationale and Recommendation</HD>
                    <P>Nitrous oxide is a widely used inhalation anaesthetic and is listed on the 2023 WHO Model List of Essential Medicines and Essential Medicines List for Children. While the Committee acknowledged the concerns raised by some countries, it recommended that nitrous oxide not proceed to critical review because of the absence of evidence of illicit manufacture and of common trading across borders, and in recognition of its global therapeutic value. The Committee recommended that nitrous oxide not proceed to critical review but be kept under surveillance by the WHO Secretariat.</P>
                </EXTRACT>
                <HD SOURCE="HD1">III. Discussion</HD>
                <P>Although WHO has made specific scheduling recommendations for each of the drug substances, the CND is not obliged to follow the WHO recommendations. Options available to the CND for substances considered for control under the 1971 Convention include the following: (1) accept the WHO recommendations; (2) accept the recommendations to control but control the drug substance in a schedule other than that recommended; or (3) reject the recommendations entirely.</P>
                <P>
                    Butonitazene (chemical name: N,N-diethyl-2-[(4-butoxyphenyl)methyl]-5-nitro-1H-benzimidazole-1-ethanamine) is a benzimidazole synthetic opioid that functions as an agonist of the µ-opioid receptor and has similar psychoactive effects as morphine and fentanyl. Butonitazene is reported to produce euphoria after administration through various routes including smoking, oral, intranasal, and injection. It was first identified in law enforcement seizures in the United States in 2021 and has since (
                    <E T="03">i.e.,</E>
                     2021 to 2023) been identified in 63 different drug seizures. Butonitazene has also been identified in drug toxicology screens and is confirmed to have been responsible for at least one fatality in the United States. There are no commercial or approved medical uses for butonitazene. Butonitazene is controlled in schedule I of the CSA and will not require additional permanent controls if it is placed in Schedule I of the 1961 Single Convention.
                    <PRTPAGE P="8689"/>
                </P>
                <P>3-Chloromethcathinone (3-CMC) (chemical name: 1-(3-chlorophenyl)-2-(methylamino)propan-1-one) is a synthetic cathinone that functions to inhibit reuptake of the dopamine, serotonin, and norepinephrine transporters in the central nervous system. Functionally this increases the concentration of these neurotransmitters which leads to psychostimulatory effects. Humans and animals have demonstrated clinical signs of agitation, restlessness, seizures, high blood pressure, and increased locomotor activity. The appearance of 3-CMC on the illicit drug market is similar to other designer drugs trafficked for their psychoactive effects. There are no commercial or approved medical uses for 3-CMC in the United States. Methcathinone was controlled in Schedule I of the CSA on October 15, 1993. As a positional isomer of methcathinone, 3-CMC is controlled in Schedule I of the CSA. As such, additional permanent controls will not be needed if 3-CMC is placed in Schedule II of the Convention on Psychotropic Substances, 1971.</P>
                <P>Dipentylone (chemical name: 1-(1,3-benzodioxol-5-yl)-2-(dimethylamino)pentan-1-one, also known as N,N-dimethylpentylone, dimethylpentylone or bk-DMBDP) is a synthetic cathinone that produces psychostimulant effects similar to cathinone. Dipentylone functions by increasing the concentration of dopamine, serotonin, and norepinephrine in the central nervous system similar to amphetamines. Anecdotal reports indicate that dipentylone produces clinical effects of insomnia, hallucinations, paranoia, and confusion. As of 2021, dipentylone was identified in 8,368 drug seizures, and was confirmed as the cause of death in at least nine fatalities in 2023. There are no commercial or approved medical uses for dipentylone in the United States. Pentylone was controlled in Schedule I of the CSA on March 4, 2016. As a positional isomer of pentylone, dipentylone is controlled in Schedule I of the CSA. As such, additional permanent controls will not be needed if dipentylone is placed in Schedule II of the Convention on Psychotropic Substances, 1971.</P>
                <P>
                    2-Fluorodeschloroketamine (chemical name: 2-(2-fluorophenyl)-2-(methylamino)cyclohexan-1-one), fluoroketamine, or 2-FDCK) is an arylcyclohexylamine that is related to ketamine and phencyclidine (PCP). 2-FDCK is thought to function as an N-methyl-D-aspartate receptor antagonist and produce effects similar to other dissociative anesthetics (
                    <E T="03">e.g.,</E>
                     ketamine). According to anecdotal reports, these effects include dissociation, hallucination, confusion, agitation, stimulation, and tachycardia and hypertension. Studies in animals indicate that 2-FDCK was self-administered (
                    <E T="03">i.e.,</E>
                     produced reinforcing effects) and produced a drug cue similar to that of ketamine. As a result, animal data suggests that 2-FDCK has an abuse potential similar to ketamine. 2-FDCK has not been detected in law enforcement seizures, or in toxicology screens in the United States. There are no commercial or approved medical uses for 2-FDCK, and it is not a controlled substance under the CSA. As such, additional permanent controls will be necessary to fulfill U.S. obligations if 2-FDCK is controlled under Schedule II of the Convention on Psychotropic Substances, 1971.
                </P>
                <P>
                    Bromazolam (chemical name: 8-bromo-1-methyl-6-phenyl-4H-[1,2,4]triazolo[4,3-a][1,4]benzodiazepine) is a triazolobenzodiazepine that functions as a positive allosteric modulator of γ-aminobutyric acid A (GABA
                    <E T="52">A</E>
                    ) channels thereby decreasing neuronal activity. Similar to other benzodiazepines, such as alprazolam, it produces sedative and anxiolytic effects typically taken after oral administration or through injection. Unconfirmed anecdotal reports indicate that it can also produce hypnotic, muscle relaxant, and euphoric effects as well as physical dependence demonstrated through a withdrawal syndrome. Since 2021, bromazolam has been detected in 637 law enforcement seizures and has been implicated in 53 fatalities. There are no commercial or approved medical uses for bromazolam in the United States, and it is not a controlled substance under the CSA. As such, additional permanent controls will be necessary to fulfill U.S. obligations if bromazolam is controlled under Schedule IV of the Convention on Psychotropic Substances, 1971.
                </P>
                <P>FDA, on behalf of the Secretary of HHS, invites interested persons to submit comments on the notifications from the United Nations concerning these drug substances. FDA, in cooperation with the National Institute on Drug Abuse, will consider the comments on behalf of HHS in evaluating the WHO scheduling recommendations. Then, under section 201(d)(2)(B) of the CSA, HHS will recommend to the Secretary of State what position the United States should take when voting on the recommendations for control of substances under the 1971 Convention at the CND meeting in March 2024.</P>
                <P>Comments regarding the WHO recommendations for control of butonitazene under the 1961 Single Convention will also be forwarded to the relevant Agencies for consideration in developing the U.S. position regarding narcotic substances at the CND meeting.</P>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02573 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4164-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Cancer Institute; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>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.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Cancer Institute Special Emphasis Panel; Cancer Technologies for Global Health.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 13, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:30 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Cancer Institute at Shady Grove, 9609 Medical Center Drive, Room 7W238, Rockville, Maryland 20850 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Jeffrey E. DeClue, Ph.D., Scientific Review Officer, Research Technology and Contract Review Branch, Division of Extramural Activities, National Cancer Institute, NIH, 9609 Medical Center Drive, Room 7W238, Rockville, Maryland 20850, 240-276-6371, 
                        <E T="03">decluej@mail.nih.gov</E>
                        .
                    </P>
                    <P>This notice is being published less than 15 days prior to the meeting due to the timing limitations imposed by the review and funding cycle.</P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.392, Cancer Construction; 93.393, Cancer Cause and Prevention Research; 93.394, Cancer Detection and Diagnosis Research; 93.395, Cancer Treatment Research; 93.396, Cancer Biology Research; 93.397, Cancer Centers Support; 93.398, Cancer Research Manpower; 93.399, Cancer Control, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <PRTPAGE P="8690"/>
                    <DATED>Dated: February 5, 2024. </DATED>
                    <NAME>Melanie J. Pantoja, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02593 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Institute of General Medical Sciences; Amended Notice of Meeting</SUBJECT>
                <P>
                    Notice is hereby given of a change in the meeting of the National Institute of General Medical Sciences Special Emphasis Panel, Review of PRAT and K99/R00 MOCSAC Applications. March 04, 2024, 10:30 a.m. to March 05, 2024, 06:30 p.m., National Institute of General Medical Sciences, Natcher Building, 45 Center Drive, Bethesda, Maryland, 20892 which was published in the 
                    <E T="04">Federal Register</E>
                     on January 19, 2024, FR. Doc. 2024-00950, 89 FR 3671.
                </P>
                <P>This notice is being amended to change the name of the panel from Review of PRAT and K99/R00 MOCSAC Applications to the Review of PRAT and K99/R00 MOSAIC Applications. The meeting date, time, and location will stay the same. The meeting is closed to the public.</P>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Miguelina Perez,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02582 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Institute on Aging; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>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 contract proposals and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the contract proposals, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute on Aging Special Emphasis Panel; SBIR contract topic 010.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 15, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate contract proposals.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institute on Aging, Gateway Building, 7201 Wisconsin Avenue, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Nijaguna Prasad, Ph.D., Scientific Review Officer, Scientific Review Branch, National Institute on Aging, 7201 Wisconsin Avenue, Gateway Bldg., Suite 2W200, (301) 496-9667, 
                        <E T="03">prasadnb@nia.nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.866, Aging Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Miguelina Perez, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02583 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>Center for Scientific Review; Notice of Closed Meetings</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meetings.</P>
                <P>The meetings 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.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Center for Scientific Review Special Emphasis Panel; Targeted Cancer Therapies.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 4, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         12:00 p.m. to 5:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Lawrence Ka-Yun Ng, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 6152, MSC 7804, Bethesda, MD 20892, 301-435-1719, 
                        <E T="03">ngkl@csr.nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Biological Chemistry and Macromolecular Biophysics Integrated Review Group; Chemical Synthesis and Biosynthesis Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 6-7, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Shan Wang, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Bethesda, MD 20892, (301) 496-4390, 
                        <E T="03">shan.wang@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Emerging Technologies and Training Neurosciences Integrated Review Group; Bioengineering of Neuroscience, Vision and Low Vision Technologies Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 7-8, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:00 a.m. to 7:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Tina Tze-Tsang Tang, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Suite 3030, Bethesda, MD 20817, (301) 435-4436, 
                        <E T="03">tangt@mail.nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Center for Scientific Review Special Emphasis Panel; Member Conflict: Health Services and Systems.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 8, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Mary Kate Baker, DRPH, Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Bethesda, MD 20892, (301) 594-5117, 
                        <E T="03">katie.baker2@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Center for Scientific Review Special Emphasis Panel; Small Business: Computational, Modeling, and Biodata Management.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 8, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 8:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Marie-Jose Belanger, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Rm. 6188, MSC 7804, Bethesda, MD 20892, 301-435-1267, 
                        <E T="03">belangerm@csr.nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.306, Comparative Medicine; 93.333, Clinical Research, 93.306, 93.333, 93.337, 93.393-93.396, 93.837-93.844, 93.846-93.878, 93.892, 93.893, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Miguelina Perez,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02581 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8691"/>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Institute on Drug Abuse; Notice of Closed Meetings</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meetings.</P>
                <P>The meetings 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.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute on Drug Abuse Special Emphasis Panel; Field-Deployable, Low-Cost Point-of-Need Approaches and Technologies to Lower the Barriers to Substance Use Disorders (SUD) Diagnosis and Treatment.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 6, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 4:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, National Institute on Drug Abuse, 301 North Stonestreet Avenue, Bethesda, MD 20892.
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Caitlin Elizabeth Angela Moyer, Ph.D., Scientific Review Officer, Scientific Review Branch, National Institute on Drug Abuse, NIH, 301 North Stonestreet Avenue, MSC 6021, Bethesda, MD 20892, (301) 443-4577, 
                        <E T="03">caitlin.moyer@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute on Drug Abuse Special Emphasis Panel; NIDA L Conflict SEP.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 15, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         2:00 p.m. to 3:30 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications and/or proposals.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, National Institute on Drug Abuse, 301 North Stonestreet Avenue, Bethesda, MD 20892.
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Sudhirkumar Udhavrao Yanpallewar, M.D., Scientific Review Officer, Scientific Review Branch, National Institute on Drug Abuse, NIH, 301 North Stonestreet Avenue, MSC 6021, Bethesda, MD 20892, (301) 443-4577, 
                        <E T="03">sudhirkumar.yanpallewar@nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.277, Drug Abuse Scientist Development Award for Clinicians, Scientist Development Awards, and Research Scientist Awards; 93.278, Drug Abuse National Research Service Awards for Research Training; 93.279, Drug Abuse and Addiction Research Programs, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Lauren Fleck,</NAME>
                    <TITLE>Program Analyst,  Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02526 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Cancer Institute; Notice of Meeting</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of a meeting of the National Cancer Institute Council of Research Advocates.</P>
                <P>
                    The meeting will be a hybrid meeting held in-person and virtually and will be open to the public as indicated below, with attendance limited to space available. Individuals who plan to attend in-person or view the virtual meeting and need special assistance or other reasonable accommodations, should notify the Contact Person listed below in advance of the meeting. The meeting can be accessed from the NIH Videocast at the following link: 
                    <E T="03">http://videocast.nih.gov.</E>
                </P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Cancer Institute Council of Research Advocates.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 5, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 3:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         Welcome and Chairwoman's Remarks, NCI Director's Update, NCI Updates, and Legislative Update.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         Porter Neuroscience Research Center, National Institutes of Health, Building 35A, Room 610, 35 Convent Drive, Bethesda, MD 20892-2580 (Hybrid Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Amy Williams, Acting Director, NCI Office of Advocacy Relations, National Cancer Institute, NIH, 31 Center Drive, Building 31, Room 10A28, Bethesda, MD 20892, (240) 781-3406, 
                        <E T="03">williaam@mail.nih.gov.</E>
                    </P>
                    <P>Any interested person may file written comments with the committee by forwarding the statement to the Contact Person listed on this notice. The statement should include the name, address, telephone number and when applicable, the business or professional affiliation of the interested person.</P>
                    <P>
                        In the interest of security, NIH has procedures at 
                        <E T="03">https://www.nih.gov/about-nih/visitor-information/campus-access-security</E>
                         for entrance into on-campus and off-campus facilities. All visitor vehicles, including taxicabs, hotel, and airport shuttles will be inspected before being allowed on campus. Visitors attending a meeting on campus or at an off-campus federal facility will be asked to show one form of identification (for example, a government-issued photo ID, driver's license, or passport) and to state the purpose of their visit.
                    </P>
                    <P>
                        Information is also available on the Institute's/Center's home page: NCRA: 
                        <E T="03">http://deainfo.nci.nih.gov/advisory/ncra/ncra.htm,</E>
                         where an agenda and any additional information for the meeting will be posted when available.
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.392, Cancer Construction; 93.393, Cancer Cause and Prevention Research; 93.394, Cancer Detection and Diagnosis Research; 93.395, Cancer Treatment Research; 93.396, Cancer Biology Research; 93.397, Cancer Centers Support; 93.398, Cancer Research Manpower; 93.399, Cancer Control, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <NAME>Melanie J. Pantoja, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02592 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>Eunice Kennedy Shriver National Institute of Child Health and Human Development; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 1009 of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>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.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Eunice Kennedy Shriver National Institute of Child Health and Human Development Special Emphasis Panel; HEAL Initiative: Limited Competition: Clinical Outcomes of Babies with Opioid Exposure (OBOE) Study (UG1).
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 25, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:00 a.m. to 2:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Eunice Kennedy Shriver National Institute of Child Health and Human Development, 6710B Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Kimberly L. Houston, M.D., Scientific Review Branch, Eunice Kennedy Shriver National Institute of Child Health &amp; Human Development, NIH, 6710B Rockledge Drive, Rm. 2137C, Bethesda, MD 20892, (301) 827-4902, 
                        <E T="03">kimberly.houston@nih.gov.</E>
                    </P>
                    <PRTPAGE P="8692"/>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.864, Population Research; 93.865, Research for Mothers and Children; 93.929, Center for Medical Rehabilitation Research; 93.209, Contraception and Infertility Loan Repayment Program, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: February 2, 2024.</DATED>
                    <NAME>Lauren A. Fleck, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02525 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <DEPDOC>[Docket Number DHS-2024-0004]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities: DHS Civil Rights Evaluation Tool, Collection Instrument DHS Form 3095, OMB Control No. 1601-0024</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Homeland Security (DHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>60-Day notice and request for comments; revision request.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Homeland Security will submit the following Information Collection Request (ICR) to the Office of Management and Budget (OMB) for review and clearance in accordance with the Paperwork Reduction Act of 1995.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are encouraged and will be accepted until April 8, 2024. This process is conducted in accordance with 5 CFR 1320.1.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number Docket #DHS-2024-0004, at:</P>
                    <P>
                        ○ 
                        <E T="03">Federal eRulemaking Portal: http://www.regulations.gov.</E>
                         Please follow the instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name and docket number Docket #DHS-2024-0004. All comments received will be posted without change to 
                        <E T="03">http://www.regulations.gov,</E>
                         including any personal information provided.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         For access to the docket to read background documents or comments received, go to 
                        <E T="03">http://www.regulations.gov.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Recipients of Federal financial assistance from the Department of Homeland Security (DHS) are required to meet certain legal requirements relating to nondiscrimination and nondiscriminatory use of Federal funds. Those requirements include ensuring that entities receiving Federal financial assistance from the DHS do not deny benefits or services, or otherwise discriminate on the basis of race, color, national origin, disability, age, sex, or religion, in accordance with the following authorities:</P>
                <P>
                    • Title VI of the Civil Rights Act of 1964 (Title VI) Public Law 88-352, 42 U.S.C. 2000d-1 
                    <E T="03">et seq.,</E>
                     and the Department's implementing regulation, 6 CFR part 21 and 44 CFR part 7, which prohibit discrimination on the grounds of race, color, or national origin by recipients of Federal financial assistance. Title VI, through its prohibition against discrimination on the basis of national origin, requires recipients to take reasonable steps to provide meaningful access to persons who are limited English proficient (LEP). 
                    <E T="03">See Guidance to Federal Financial Assistance Recipients Regarding Title VI Prohibition Against National Origin Discrimination Affecting Limited English Proficient Persons,</E>
                     76 FR. 21755-21768 (April 18, 2011).
                </P>
                <P>• Section 504 of the Rehabilitation Act of 1973 (Section 504), Public Law 93-112, as amended by Public Law 93-516, 29 U.S.C. 794, which prohibits discrimination on the basis of disability by recipients of Federal financial assistance.</P>
                <P>
                    • Title IX of the Education Amendments of 1972 (title IX), 20 U.S.C. 1681 
                    <E T="03">et seq.,</E>
                     and the Department's implementing regulations, 6 CFR part 17, and 44 CFR part 19, which prohibits discrimination on the basis of sex in education program and activities received Federal financial assistance.
                </P>
                <P>
                    • Age Discrimination Act of 1975, Public Law 94-135, 42 U.S.C. 6101 
                    <E T="03">et seq.,</E>
                     and the Department implementing regulation at 44 CFR part 7, which prohibits discrimination on the basis of age by recipients of Federal financial assistance.
                </P>
                <P>• U.S. Department of Homeland Security regulation 6 CFR part 19, which prohibits organizations that receive financial assistance from DHS for a social service program from discriminating against beneficiaries on the basis of religion or religious belief, a refusal to hold a religious belief, or a refusal to attend or participate in a religious practice.</P>
                <P>The aforementioned civil rights authorities also prohibit retaliatory acts against individuals for participating or opposing discrimination in a complaint, investigation, or other proceeding related to prohibited discrimination.</P>
                <P>
                    DHS has an obligation to enforce nondiscrimination requirements to ensure that its federally assisted programs and activities are administered in a nondiscriminatory manner. In order to carry out its enforcement responsibilities, DHS must obtain a signed assurance of compliance and collect and review information from recipients to ascertain their compliance with applicable requirements. DHS implementing regulations and the Department of Justice regulation 
                    <E T="03">Coordination of Non-discrimination in Federally Assisted Program,</E>
                     28 CFR part 42, provide for the collection of data and information from recipients (see 28 CFR 42.406).
                </P>
                <P>
                    DHS uses DHS Form 3095: DHS Civil Rights Evaluation Tool as the primary tool to implement this information collection. DHS is revising the collection, changing 
                    <E T="03">Section 1</E>
                     of the form on 
                    <E T="03">Instructions</E>
                     to extend the deadline for initial submissions from 30 days of receipt of the Notice of Award to 60 days; to update the method of submission from email to an online portal, and to make other minor clarifying revisions. DHS is also making minor changes to 
                    <E T="03">Section 2</E>
                     of the form on 
                    <E T="03">Organization Information</E>
                     to remove the fields for reporting Grant Agreement Number and Federal Award Identification Number; DHS now obtains that information from Department data sources. In addition, DHS is making minor changes to 
                    <E T="03">Section 5</E>
                     of the form on 
                    <E T="03">Additional Information</E>
                     to streamline communication with recipients by providing a single, centralized point of contact for questions and technical assistance. Further, a minor change to Section 2 of the form on 
                    <E T="03">Organization Information</E>
                     to revise the field for reporting the organization's DUNS Number to Unique Entity ID. In 2022, the Federal Government stopped using DUNS Number to uniquely identify organizations and transitioned to using Unique Entity ID as the official identifier for entities doing business with the U.S. Government.
                </P>
                <P>DHS uses the form to collect civil rights related information from all recipients of federal financial assistance from the Department. Recipients are non-Federal entities that receive Federal financial assistance in the form of a grant, cooperative agreement, or other type of financial assistance directly from the Department and not through another recipient or “pass-through” entity. This information collection does not apply to subrecipients, Federal contractors (unless the contract includes the provision of financial assistance), nor the ultimate beneficiaries of services, financial aid, or other benefits from the Department.</P>
                <P>
                    Recipients are required to provide the information 60 days from receipt of Notice of Award. Recipient of multiple 
                    <PRTPAGE P="8693"/>
                    awards of DHS financial assistance only submit one completed form for their organization, not per award. Recipient are required to complete the form once every two years if they have an active award, not every time a grant is awarded. Entities whose award does not run a full two years are required to provide the information again if they receive a subsequent award more than two (2) years after the prior award. In responding to 
                    <E T="03">Section 4: Required Information,</E>
                     which contains the bulk of the information collection, if the recipient's responses have not changed in the two-year period since their initial submission, the recipient does not need to resubmit the information. Instead, the recipient will indicate “no change” for each applicable item.
                </P>
                <P>The purpose of the information collection is to advise recipients of their civil rights obligations and collect pertinent civil rights information to ascertain if the recipient has in place adequate policies and procedures to achieve compliance, and to determine what, if any, further action may be needed (technical assistance, training, compliance review, etc.) to ensure the recipient is able to meet its civil rights requirements and will carry out its programs and activities in a nondiscriminatory manner.</P>
                <P>Over the past three years, DHS has used the information collected via the DHS Civil Rights Evaluation Tool to identify gaps and deficiencies in recipient programs and directly help recipients address these gaps and deficiencies by providing technical assistance on developing or improving policies and procedures to prevent discrimination and ensure accessibility.</P>
                <P>DHS is transitioning the submission process from an email-based system to a new online portal platform. The portal will streamline and improve the submission process by allowing recipients to view the requirements contained in the form, report civil rights complaint and lawsuit data in a standardized chart, upload responsive documents and supporting information, and access technical assistance templates and other resources all in one space. DHS anticipates that records or files that will be used to respond to the information collection are already maintained in electronic format by the recipient, so providing the information electronically further minimizes administrative burden.</P>
                <P>When fully deployed, recipients will also be able to view and update contact information, the status of their submission with DHS, and submission due dates. If the recipient is unable to submit their information electronically, alternative arrangements will be made to submit responses in hard copy.</P>
                <P>
                    The information collection will impact some small entities (
                    <E T="03">e.g.,</E>
                     non-profit service providers, local fire departments, etc.); however, recipients will only be required to provide this information once every two years, not every time a grant is awarded. Additionally, in responding to 
                    <E T="03">Section 4: Required Information,</E>
                     if the recipient's responses have not changed in the two-year period since their initial submission, the recipient does not need to resubmit the information. This will dramatically reduce the administrative burden on recipients after the initial submission. Additionally, DHS will further minimize burden on recipients by making available sample policies, procedures, and templates to assist recipients in completing 
                    <E T="03">Section 4</E>
                     of the Form, and providing technical assistance directly to the recipient as needed.
                </P>
                <P>In accordance with the authorities identified above, the Department is required to obtain a signed assurance of compliance from recipients and to ensure that its federally assisted programs and activities are administered in a nondiscriminatory manner. If the information collection is not conducted or is conducted less frequently, the Department will not be able to fulfill its obligations to ascertain recipient compliance and enforce nondiscrimination in recipient programs. This could lead to the award of Federal financial assistance to recipients that are not complying with Federal civil rights law, and the perpetuation of discrimination in the provision of benefits and services to members of the public.</P>
                <P>There are no confidentiality assurances associated with this collection. The only privacy-sensitive information the form collects are the names of Point of Contacts from recipient organizations. Coverage for the collection of this information is provided under a Department Privacy Impact Assessment, DHS/ALL/PIA-006 General Contacts List.</P>
                <P>
                    DHS is seeking a revision of the collection for another three-year period, proposing changes to 
                    <E T="03">Section 1 Instructions, Section 2 Organization Information</E>
                     and 
                    <E T="03">Section 5 Additional Information.</E>
                     The changes to Sections 1, 2, and 5 do not impact the burden analysis for the collection. The changes in burden reflect the increase in the number of entities that are required to respond to the collection (as a result of increased Department grantmaking), increase in hourly wage rates as reported by BLS in the 2022 National Occupational Employment and Wage Estimates, increase in hourly wage rates for Federal staff as reported by Office of Personnel Management for 2023, increases in the number of staff supporting the program, and development of an online portal to streamline and modernize the submission process. Lastly, DHS is changing the name of the collection from “
                    <E T="03">DHS Civil Rights Compliance Form”</E>
                     to “
                    <E T="03">DHS Civil Rights Evaluation Tool.”</E>
                </P>
                <P>The Office of Management and Budget is particularly interested in comments which:</P>
                <P>1. 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;</P>
                <P>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;</P>
                <P>3. Enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    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, 
                    <E T="03">e.g.,</E>
                     permitting electronic submissions of responses.
                </P>
                <P>
                    <E T="03">Analysis:</E>
                </P>
                <P>
                    <E T="03">Agency:</E>
                     Department of Homeland Security (DHS).
                </P>
                <P>
                    <E T="03">Title:</E>
                     DHS Civil Rights Evaluation Tool.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     1601-0024.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Annually.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Entities Receiving Federal Financial Assistance from DHS.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     5,000.
                </P>
                <P>
                    <E T="03">Estimated Time per Respondent:</E>
                     3 hours.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     10,050.
                </P>
                <SIG>
                    <NAME>Robert Porter Dorr,</NAME>
                    <TITLE>Executive Director, Business Management Directorate.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02588 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9112-FL-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No. FR-7092-N-18]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; Matching Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Administration, Department of Housing and Urban Development (HUD).</P>
                </AGY>
                <ACT>
                    <PRTPAGE P="8694"/>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of new matching program.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to the Privacy Act of 1974, as amended by the Computer Matching and Privacy Act of 1988 and the Computer Matching and Privacy Protections Amendment of 1990 (Privacy Act), and Office of Management and Budget (OMB) guidance on the conduct of matching programs, notice is hereby given of the establishment of a matching program between the U.S. Department of Housing and Urban Development (HUD), the Department of Homeland Security, Federal Emergency management Agency (FEMA) and Federal Insurance Mitigation Administration (FIMA) and HUD Community Development Block Grant—Disaster Recovery (CDBG-DR) grantees.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Please submit comments on or before March 11, 2024. The matching program will be effective on March 11, 2024 unless comments have been received from interested members of the public that require modification and republication of the notice. The matching program will continue for 18 months from the beginning date and may be extended an additional 12 months if the conditions specified in 5 U.S.C. 552a(o)(2)(D) have been met.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit comments regarding this notice at 
                        <E T="03">www.regulations.gov</E>
                         or to the Rules Docket Clerk, Office of General Counsel, Department of Housing and Urban Development, 451 Seventh Street SW, Room 10110, Washington, DC 20410. Communications should refer to the above docket number. A copy of each communication submitted will be available for public inspection and copying between 8:00 a.m. and 5:00 p.m. weekdays at the above address.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To obtain additional information about this matching program and the contents of this Computer Matching Agreement between HUD, DHS FEMA, DHS FIMA and HUD CDBG-DR grantees please view this Computer Matching Agreement at the following website: 
                        <E T="03">https://www.hud.gov/program_offices/officeofadministration/privacy_act/cma.</E>
                    </P>
                    <P>
                        For general questions about this matching program, contact Tennille Smith Parker, Director, Office of Disaster Recovery, U.S. 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 and communication disabilities. To learn more about how to make an accessible telephone call, please visit: 
                        <E T="03">https://www.fcc.gov/consumers/guides/telecommunications-relay-service-trs.</E>
                         Facsimile inquiries may be sent to Ms. Parker at 202-708-0033. (Except for the “800” number, these telephone numbers are not toll-free.) Email inquiries may be sent to 
                        <E T="03">disaster_recovery@hud.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>HUD is providing this notice in accordance with the Privacy Act of 1974 (5 U.S.C. 552a), as amended by the Computer Matching and Privacy Protection Act of 1988 (Pub. L. 100-503) and the Computer Matching and Privacy Protection Amendments of 1990 (Pub. L. 101-508) (Privacy Act); Office of Management and Budget (OMB) Final Guidance Interpreting the Provisions of Public Law 100-503, the Computer Matching and Privacy Protection Act of 1988, 54 FR 25818 (June 19, 1989); and OMB Circular A-108, 81 FR 94424 (December 23, 2016).</P>
                <P>To support the prevention of duplication of benefits, HUD will request data from DHS FEMA and DHS FIMA on an as-needed basis to share with Community Development Block Grant disaster recovery (CDBG-DR) grantees, and make changes where HUD deems necessary to avoid confusion. CDBG-DR grantees will conduct a DOB review for CDBG-DR grant-funded programs and activities. HUD's data request will be based on the specific program requirements specified in an approved CDBG-DR grantee action plan. CDBG-DR grantees will use FEMA data received through HUD to facilitate expedited program implementation while preventing the duplication of benefits already received from FEMA. All data sharing from HUD to CDBG-DR grantees will occur in accordance with agreements between HUD and the CDBG-DR grantees that address requirements related to the use and protection of the data.</P>
                <P>
                    <E T="03">Participating Agencies:</E>
                     U.S. Department of Housing and Urban Development (HUD), Department of Homeland Security, Federal Emergency Management Agency (DHS-FEMA) Department of Homeland Security, Federal Insurance Mitigation Administration (DHS-FIMA), and Community Development Block Grant—Disaster Recovery (CDBG-DR) grantees.
                </P>
                <P>
                    <E T="03">Authority for Conducting the Matching Program:</E>
                </P>
                <P>A. Section 12 of the Stafford Act, as amended, at 42 U.S.C. 5155, requires each Federal agency that administers any program providing financial assistance because of a major disaster or emergency to assure that no individual or entity receives duplicate financial assistance under any program, from insurance, or through any other source. The Stafford Act, 42 U.S.C. 5155(c), requires FEMA or HUD (whichever agency provided the duplicative assistance) to recover all duplicative assistance from the recipient when the head of such agency considers it to be in the best interest of the Federal Government. For CDBG-DR grants, HUD does not directly make awards to grantee program applicants; however, HUD imposes the requirements of section 312 on CDBG-DR grantees. Additionally, appropriations acts that make CDBG-DR funds available, including those listed in paragraph II.C.8. of this Agreement, require CDBG-DR grantees to have adequate procedures to prevent the duplication of benefits. HUD enforces these requirements on CDBG-DR grantees using its statutory and regulatory remedies for noncompliance in section 111 of title I of the Housing and Community Development Act of 1974 (42 U.S.C. 5311) and regulations at 24 CFR part 570 and 2 CFR part 200.</P>
                <P>B. Section 408(i) of the Stafford Act, 42 U.S.C. 5174(i), directs and authorizes FEMA, in carrying out section 408 (Federal Assistance to Individuals and Households), to “develop a system, including an electronic database,” to:</P>
                <P>1. Verify the identity and address of recipients of assistance to provide reasonable assurance that payments are made only to an individual or household that is eligible for such assistance,</P>
                <P>2. Minimize the risk of making duplicative payments or payments for fraudulent claims,</P>
                <P>3. Collect any duplicate payment on a claim or reduce the amount of subsequent payments to offset the amount of any such duplicate payment,</P>
                <P>4. Provide instructions to recipients of assistance regarding the proper use of any such assistance, regardless of how such assistance is distributed, and</P>
                <P>5. Conduct an expedited and simplified review and appeal process for an individual or household whose application for assistance is denied.</P>
                <P>C. Executive Order 13411, “Improving Assistance for Disaster Victims,” 71 FR 52729 (August 29, 2006), calls on Federal agencies to “reduce unnecessarily duplicative application forms and processes for Federal disaster assistance,” which includes processing benefits applications submitted by individuals, businesses, or other entities for the same disaster.</P>
                <P>
                    D. The FEMA-008 Disaster Recovery Assistance Files System of Records, 87 FR 7852 (February 10, 2022), and the 
                    <PRTPAGE P="8695"/>
                    FEMA-003 National Flood Insurance Program Files System of Records Notice, 79 FR 28747 (May 19, 2014), authorizes FEMA to provide Federal agencies with access to FEMA's electronic records of individuals and households receiving assistance to make available any additional assistance to the affected individuals and households and to prevent duplication of benefits.
                </P>
                <P>1. Pursuant to Routine Use I.1 of the FEMA-008 Disaster Recovery Assistance Files System of Records, 87 FR 7852 (February 10, 2022; Routine Use I.1), FEMA may disclose applicant information to other Federal entities with programs that make available disaster assistance to individuals and households, administer a disaster-related program, and/or give preference of priority to disaster applicants, including those that evacuate from a declared state to another state, and/or to prevent a duplication of efforts or benefits.</P>
                <P>2. Pursuant to Routine Use I.2 of the FEMA-008 Disaster Recovery Assistance Files System of Records, 87 FR 7852 (February 10, 2022; Routine Use I.2), FEMA may disclose applicant information to State, Tribal, and Territorial agency programs that make available disaster assistance to individuals and households, and/or give preference of priority to disaster applicants, including those that evacuate from a declared state to another state, and/or to prevent a duplication of efforts or benefits.</P>
                <P>3. Pursuant to Routine Use S of the FEMA-008 Disaster Recovery Assistance Files System of Records, 87 FR 7852 (February 10, 2022; Routine Use S), FEMA may share information with other Federal, State, or local government agencies under approved computer-matching programs for the purposes articulated in subsection (a)(8)(A) of the Privacy Act.</P>
                <P>4. Pursuant to Routine Use I of the FEMA-003 National Flood Insurance Program Files System of Records Notice, 79 FR 28747 (May 19, 2014), FEMA may share National Flood Insurance Program Files with Federal, State, local, Tribal, or Territorial government agencies to prevent duplication of benefits or to address needs unmet by eligible, ineligible, or partially eligible NFIP claims payments.</P>
                <P>5. Pursuant to Routine Use L of the FEMA-003 National Flood Insurance Program Files System of Records Notice, 79 FR 28747 (May 19, 2014), FEMA may share National Flood Insurance Program Files with State, local, and Tribal government agencies to ascertain the degree of financial burdens they expect to assume in the event of a flooding disaster within its jurisdiction.</P>
                <P>E. At times, the President may authorize both emergency sheltering and section 408 Federal assistance to individuals and households, pursuant to either a major disaster under section 403, at 42 U.S.C. 5170b, or an emergency under section 502 of the Stafford Act, 42 U.S.C. 5192. Essential Assistance, pursuant to section 403(a)(3)(B) of the Stafford Act, 42 U.S.C. 5170b, authorizes emergency sheltering, including both congregate and non-congregate sheltering, to meet the immediate needs of disaster survivors for a major disaster. Additionally, Federal assistance where necessary to prevent human suffering under section 502(a)(8) authorizes emergency sheltering for an emergency.</P>
                <P>F. Essential Assistance pursuant to section 403(a)(3)(B) of the Stafford Act, 42 U.S.C. 5170b authorizes FEMA to provide emergency sheltering, including non-congregate sheltering to meet the immediate needs of disaster survivors. The Debt Collection Improvement Act of 1996, 31 U.S.C. 3325(d) and 7701(c)(1), requires Federal agencies to collect the Taxpayer Identification Number (TIN) or Social Security Number (SSN) of each person who receives payments from the Federal Government; and each person doing business with the Federal Government is required to furnish his or her TIN.</P>
                <P>6. For the purposes of 31 U.S.C. 7701, a person is doing business with the Federal Government if the person is:</P>
                <P>i. A lender or servicer in a Federal guaranteed or insured loan program administered by a Federal agency,</P>
                <P>ii. An applicant for, or recipient of, a Federal license permit, right-of-way, grant, or benefit payment administered by a Federal agency,</P>
                <P>iii. A contractor of a Federal agency,</P>
                <P>iv. Assessed a fine, fee, royalty, or penalty by a Federal agency, or</P>
                <P>v. In a relationship with a Federal agency that may give rise to a receivable due to that agency such as a partner of a borrower in, or a guarantor of, a Federal direct or insured loan administered by the Federal agency.</P>
                <P>7. Each Federal agency must inform each person required to disclose his or her TIN of the agency's intent to use such number for purposes of collecting and reporting on any delinquent amounts arising out of such person's relationship with the Federal Government.</P>
                <P>G. HUD's System of Records Notice (SORN) provides individuals with notice of HUD's intended uses of information contained within the following systems of records:</P>
                <P>1. Inventory Management System, also known as the Public and Indian Housing Information Center (IMS/PIC), HUD/PIH.01, 88 FR 17004 (March 21, 2023),</P>
                <P>2. Enterprise Income Verification (EIV), HUD/PIH-5, 87 FR 50635 (August 17, 2022), and</P>
                <P>(a) 3.</P>
                <P>(b) Tenant Rental Assistance Certification System (TRACS), HUD/HOU-11, 88 FR 45234 (July 14, 2023).</P>
                <P>The applicable routine uses for IMS/PIC are Routine Use 10 and 11. The applicable routine use for EIV is Routine Use D. The applicable routine use for TRACS is Routine Use 13.</P>
                <P>H. The appropriations acts that authorize and appropriate supplemental CDBG-DR assistance lay out specific requirements, some of which may vary by appropriation. These appropriations acts impose requirements related to the (1) prevention of fraud, waste, and abuse, (2) order of assistance, and (3) prevention of duplication of benefits on HUD or its CDBG-DR grantees, as directed by the applicable act.</P>
                <P>The appropriations acts also require HUD to make allocations based on a determination of unmet need in the “most impacted and distressed areas” resulting from major disasters.</P>
                <P>
                    Legal authority for CDBG-DR assistance is derived from title I of the Housing and Community Development Act of 1974 (42 U.S.C. 5301 
                    <E T="03">et seq.</E>
                    ); subsequent appropriations acts making CDBG-DR assistance available; the following prior appropriations acts—
                </P>
                <FP SOURCE="FP-1">Public Laws 117-328, 117-180, 117-43, 116-20, 115-254, 115-123, 115-56, 115-31, 114-254, 114-223, 114-113, 113-2, 112-55, 111-212, 110-329, 110-252, 110-116, 109-234, 109-148, 108-324, 107-206, 107-117, 107-73, 107-38, 106-31, 105-277, 105-276, 105-174, 105-18, 104-134, 104-19, 103-327, 103-211, 103-75, and 103-50</FP>
                <FP>
                    —and by the notices published in the 
                    <E T="04">Federal Register</E>
                     that govern CDBG-DR grant assistance including the 
                    <E T="03">Updates to Duplication of Benefits Requirements Under the Stafford Act for Community Development Block Grant (CDBG) Disaster Recovery Grantees</E>
                     at 84 FR 28836 (June 20, 2019).
                </FP>
                <P>I. The HUD regulation at 24 CFR 982.352(c) prohibits a family from receiving the benefit of Section 8 tenant-based assistance under the Housing Choice Voucher Program while also receiving the benefit of any of the following forms of other housing subsidy for the same or a different unit:</P>
                <P>1. Public or Indian housing assistance,</P>
                <P>
                    2. Section 8 assistance (including other tenant-based assistance) under 
                    <PRTPAGE P="8696"/>
                    section 8 of the U.S. Housing Act of 1937, 42 U.S.C. 1437f,
                </P>
                <P>3. Assistance under former section 23 of the United States Housing Act of 1937 (before amendment by the Housing and Community Development Act of 1974),</P>
                <P>4. Section 101 of the Housing and Urban Development Act of 1965, 12 U.S.C. 1701s (section 101 rent supplements),</P>
                <P>5. Section 236 of the National Housing Act, 12 U.S.C. 1715z-1 (Section 236 rental assistance payments),</P>
                <P>
                    6. Tenant-based assistance under the HOME Investment Partnerships Program (HOME) authorized by Title II of the Cranston-Gonzalez National Affordable Housing Act, 42 U.S.C. 12701 
                    <E T="03">et seq.,</E>
                </P>
                <P>
                    7. Rental assistance payments under section 521 of the Housing Act of 1949, 42 U.S.C. 1441 
                    <E T="03">et seq.</E>
                     (a program of the Rural Development Administration),
                </P>
                <P>8. Any local or State rent subsidy,</P>
                <P>9. Section 202 of the Housing Act of 1959, 12 U.S.C. 1701q, as amended (Section 202 supportive housing for the elderly),</P>
                <P>8. Section 811 of the Cranston-Gonzalez National Affordable Housing Act, as amended, 42 U.S.C. 8013 (Section 811 supportive housing for persons with disabilities),</P>
                <P>9. Section 202 projects for non-elderly persons with disabilities (Section 162 assistance) authorized by section 162 of the Housing and Community Development Act of 1987, 12 U.S.C. 1701a note, amending section 202(h) of the Housing Act of 1959, or</P>
                <P>10. Any other duplicative Federal, State, or local housing subsidy, as determined by HUD. For this purpose, “housing subsidy” does not include the housing component of a welfare payment, a Social Security payment received by the family, or a rent reduction because of a tax credit.</P>
                <P>11. HUD imposes grant agreement terms that implement flood insurance requirements such as section 582 of the National Flood Insurance Reform Act of 1994, 42 U.S.C. 5154a, and related regulations at 24 CFR 58.6(b), that prohibits the use of CDBG-DR grants to make a payment to a person for repair, replacement or restoration for flood damage to any personal, residential or commercial property if: (1) the person had previously received Federal flood disaster assistance conditioned on obtaining and maintaining flood insurance; and (2) the person failed to obtain and maintain flood insurance.</P>
                <P>
                    <E T="03">Purpose:</E>
                     This Agreement establishes a computer matching program between FEMA, HUD, and CDBG-DR grantees identified in Appendix F. FEMA and HUD will make efforts to assist disaster survivors with securing emergency housing solutions. FEMA, HUD, and CDBG-DR grantees will comply with requirements to prevent duplication of benefits between FEMA and HUD sources of assistance and CDBG-DR grantees will use FEMA data in their CDBG-DR process. The computer matching program will serve three purposes, as follows.
                </P>
                <P>1. To transition HUD housing recipients, whose HUD homes are uninhabitable due to a declared disaster or emergency with Individual Assistance (IA) authorized, from emergency sheltering or FEMA housing assistance back into HUD-assisted housing. FEMA will quickly and efficiently match pre-disaster HUD housing program recipients with emergency sheltering or housing assistance recipients. Matching allows for early coordination between FEMA and HUD regarding HUD clients who are receiving emergency sheltering or FEMA housing assistance. The goal is to identify HUD housing program recipients participating in FEMA programs and return them to HUD housing assistance while also preventing duplication of individual benefits.</P>
                <P>2. To allow HUD to develop the funding formulas to request additional appropriations from Congress and allocate funding for CDBG-DR grant awards. Data associated with this Agreement will be used by HUD to calculate the amount of HUD's CDBG-DR grants, which are based on the number of unmet needs for the disaster. HUD performs a complex grants formulation process using Personally Identifiable Information (PII) data from FEMA and the Small Business Administration (SBA) to generate its CDBG-DR grant allocations and figures estimating unmet disaster needs for OMB and Congress.</P>
                <P>CDBG-DR grantees will agree to the terms of this CMA and sign the grantee signatory page in Appendix D. HUD will then provide data covered by this Agreement to the applicable CDBG-DR grantee so the CDBG-DR grantee can start planning and marketing the use of CDBG-DR grant funds. This data is not used for the determination of benefits.</P>
                <P>3. To support duplication of benefit checks conducted by CDBG-DR grantees for CDBG-DR grant-funded programs and compliance with requirements in 42 U.S.C. 5154a and 24 CFR 58.6(b) that prohibit assistance for repair, replacement or restoration for flood damage to any personal, residential or commercial property in certain cases when flood insurance is not obtained and maintained, HUD will request IHP and NFIP data from FEMA on an as-needed basis to share with CDBG-DR grantees. HUD's data request will be based on the specific program requirements specified in a CDBG-DR grantee Action Plan (including proposed action plans), such as data for all survivors meeting specific criteria related to tenure, geography, and type of FEMA benefit receipt. The data will be provided to facilitate expedited program implementation while preventing the duplication of benefits already received from FEMA. NFIP data will also be used to determine whether an applicant for CDBG-DR assistance to repair, replace, or restore personal residential or commercial property failed to obtain and maintain flood insurance. All sharing of data covered by this Agreement from HUD to CDBG-DR grantees will occur in accordance with the terms of this CMA, and all CDBG-DR grantees that request or receive this data will sign the grantee signatory page in Appendix D. FEMA will support HUD by providing data analysis and FEMA assistance data to HUD.</P>
                <P>
                    <E T="03">Categories of Individuals:</E>
                     DHS/FEMA data in this matching program includes individuals that have applied for or expressed interest in disaster assistance or . HUD data in this matching program concerns individuals who have applied for or received assistance via HUD assistance programs.
                </P>
                <P>
                    <E T="03">Categories of Records:</E>
                     Data elements disclosed by each agency in this matching program are as follows:
                </P>
                <FP SOURCE="FP-2">A. From DHS/FEMA to HUD:</FP>
                <FP SOURCE="FP1-2">• Name (First and Last of Applicant and Co-applicant)</FP>
                <FP SOURCE="FP1-2">• Date of Birth (Applicant and Co-Applicant)</FP>
                <FP SOURCE="FP1-2">• Social Security Number (last 4 of Applicant and Co-applicant)</FP>
                <FP SOURCE="FP1-2">• Phone Number (Applicant Alternate Phone Number, Applicant Current Phone Number, Co-applicant Current Phone Number)</FP>
                <FP SOURCE="FP1-2">• Email Address of Applicant</FP>
                <FP SOURCE="FP1-2">• Applicant Registration Number</FP>
                <FP SOURCE="FP1-2">• Current Mailing Address (Street, City, County, State, Zip Code)</FP>
                <FP SOURCE="FP1-2">• Current Location (as identified in applicant registration and applicant information screen)</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Latitude and Longitude</FP>
                <FP SOURCE="FP1-2">• Damaged Address (Street, City, County, State, Zip Code + 4 Digit Ext.)</FP>
                <FP SOURCE="FP1-2">• Access and Functional Needs (Y/N)</FP>
                <FP SOURCE="FP1-2">• Household Member Age Range (Under 5 years, 5 to 17 years, 18 to 64 years, 65 and above)</FP>
                <FP SOURCE="FP1-2">
                    • Number of Household Members
                    <PRTPAGE P="8697"/>
                </FP>
                <FP SOURCE="FP1-2">• Number of Dependents in Household</FP>
                <FP SOURCE="FP1-2">• Current Hotel (Name, Address, City, County)</FP>
                <FP SOURCE="FP1-2">• Initial Rental Assistance Approved Date</FP>
                <FP SOURCE="FP1-2">• Direct Housing First Licensed-In Date</FP>
                <FP SOURCE="FP1-2">• Last Continued Temporary Housing Assistance Date</FP>
                <FP SOURCE="FP1-2">• Small Business Administration (SBA) HAPP Referral Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Census Block Group ID (if applicable)</FP>
                <FP SOURCE="FP1-2">• Cause(s) of Damage from Inspection</FP>
                <FP SOURCE="FP1-2">• Destroyed Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Disaster Number</FP>
                <FP SOURCE="FP1-2">• Flood Zone</FP>
                <FP SOURCE="FP1-2">• High Water Mark Location</FP>
                <FP SOURCE="FP1-2">• High Water Depth in Inches</FP>
                <FP SOURCE="FP1-2">• Habitability Repairs Required (Y/N)</FP>
                <FP SOURCE="FP1-2">• Gross Income (as reported at Registration)</FP>
                <FP SOURCE="FP1-2">• Insurance Types (Insurance Code)</FP>
                <FP SOURCE="FP1-2">• Level of Damage</FP>
                <FP SOURCE="FP1-2">• Owner/Renter</FP>
                <FP SOURCE="FP1-2">• Personal Property Total FEMA Verified Loss (FVL)Amount</FP>
                <FP SOURCE="FP1-2">• Personal Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP1-2">• Real Property Total FVL Amount (Aggregated for all REAL PROPERTY FVL)</FP>
                <FP SOURCE="FP1-2">• Real Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP1-2">• Residence Type</FP>
                <FP SOURCE="FP1-2">• FEMA Inspection Completed (Y/N)</FP>
                <FP SOURCE="FP1-2">• Primary Residence (RI) (Yes/No)</FP>
                <FP SOURCE="FP1-2">• Household Member Age and Name (First and Last)</FP>
                <FP SOURCE="FP1-2">• Insurance Settlement Flood Amount</FP>
                <FP SOURCE="FP1-2">• Insurance Settlement Other Amount</FP>
                <FP SOURCE="FP1-2">• Non-Compliant with Flood Insurance Requirement NCOMP Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Temporary Housing Unit (THU)—Latest Currently Licensed-In Date</FP>
                <FP SOURCE="FP1-2">• Total Housing Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Total Housing Assistance Approved Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Other Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Total Other Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP1-2">• Total Other Needs Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Total Other Needs Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP1-2">• Total Personal Property Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Total Personal Property Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Repair Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Total Repair Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Replacement Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-2">B. From HUD to FEMA:</FP>
                <FP SOURCE="FP1-2">• Name (First and Last of Recipient and Co-recipient),</FP>
                <FP SOURCE="FP1-2">• Social Security Number (last 4 digits of Recipient and Co-recipient),</FP>
                <FP SOURCE="FP1-2">• Date of Birth (Recipient and Co-recipient),</FP>
                <FP SOURCE="FP1-2">• Address (Street Address, State, City, County, Zip Code),</FP>
                <FP SOURCE="FP1-2">• Number of Household Members,</FP>
                <FP SOURCE="FP1-2">• HUD Program Code (Program Type: H1-Section 8 (Multifamily), H4-Section 236 (Multifamily), H7-202/PRAC (Multifamily), P-Public Housing, PBV—Project Based Voucher, TBV-Tenant Based Voucher, HV-Homeownership Voucher, CE-Certificate, MR-Mod Rehab)</FP>
                <FP SOURCE="FP1-2">• HUD Rehoused (Y/N/Unknown),</FP>
                <FP SOURCE="FP1-2">• HUD Project Code,</FP>
                <FP SOURCE="FP1-2">• HUD Public Housing Agency (PHA) Code,</FP>
                <FP SOURCE="FP1-2">• HUD Date of Recertification.</FP>
                <FP SOURCE="FP-2">C. From HUD to HUD Grantee:</FP>
                <FP SOURCE="FP1-2">• Alternate Current Contact Phone Number</FP>
                <FP SOURCE="FP1-2">• SBA Referral Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Co-registrant Date of Birth</FP>
                <FP SOURCE="FP1-2">• Co-registrant First Name</FP>
                <FP SOURCE="FP1-2">• Co-registrant Last Name</FP>
                <FP SOURCE="FP1-2">• Co-registrant SSN</FP>
                <FP SOURCE="FP1-2">• Current Contact Phone Number</FP>
                <FP SOURCE="FP1-2">• Current Location</FP>
                <FP SOURCE="FP1-2">• Current Mailing 5 Digit Zip Code</FP>
                <FP SOURCE="FP1-2">• Current Mailing Address City</FP>
                <FP SOURCE="FP1-2">• Current Mailing Address Street</FP>
                <FP SOURCE="FP1-2">• Current Mailing State</FP>
                <FP SOURCE="FP1-2">• Current Mailing Zip 4 Digit Extension</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Address County</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Latitude</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Longitude</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Address 5 Digit Zip Code</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Address City</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Address Street</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling State</FP>
                <FP SOURCE="FP1-2">• Damaged Dwelling Zip Code 4 Digit Extension</FP>
                <FP SOURCE="FP1-2">• Dependents (Number in Household)</FP>
                <FP SOURCE="FP1-2">• Destroyed Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Disaster Number</FP>
                <FP SOURCE="FP1-2">• FEMA Inspection Completed (Y/N)</FP>
                <FP SOURCE="FP1-2">• FEMA Registration Number</FP>
                <FP SOURCE="FP1-2">• Flood Zone</FP>
                <FP SOURCE="FP1-2">• Gross Income</FP>
                <FP SOURCE="FP1-2">• High Water Mark Location</FP>
                <FP SOURCE="FP1-2">• High Water Depth in Inches</FP>
                <FP SOURCE="FP1-2">• Household Member Age</FP>
                <FP SOURCE="FP1-2">• Household Member First Name</FP>
                <FP SOURCE="FP1-2">• Household Member Last Name</FP>
                <FP SOURCE="FP1-2">• Inspection Completion (Y/N)</FP>
                <FP SOURCE="FP1-2">• Insurance Settlement Flood Amount</FP>
                <FP SOURCE="FP1-2">• Insurance Settlement Other Amount</FP>
                <FP SOURCE="FP1-2">• Insurance Type (Insurance Code)</FP>
                <FP SOURCE="FP1-2">• NCOMP Flag (Y/N)</FP>
                <FP SOURCE="FP1-2">• Owner/Renter</FP>
                <FP SOURCE="FP1-2">• Personal Property Total FVL Amount (Aggregated for all PERSONAL PROPERTY FVL one field replaces all fields related to personal property damage) Personal Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP1-2">• Primary Residence (RI) (Yes/No)</FP>
                <FP SOURCE="FP1-2">• Real Property Total FVL Amount (Aggregated for all REAL PROPERTY FVL (one field replaces all fields related to real property damage) Real Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP1-2">• Registrant Date of Birth</FP>
                <FP SOURCE="FP1-2">• Registrant First Name</FP>
                <FP SOURCE="FP1-2">• Registrant Last 4 Digits of SSN</FP>
                <FP SOURCE="FP1-2">• Registrant Last Name</FP>
                <FP SOURCE="FP1-2">• Residence Type</FP>
                <FP SOURCE="FP1-2">• Temporary Housing Unit (THU)—Latest Currently Licensed-in Date</FP>
                <FP SOURCE="FP1-2">• Total Housing Assistance Approved Amount (Aggregated Eligibility Amount) Total Housing Assistance Approved Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Other Assistance Approved Amount (Aggregated Eligibility Amount) Total Other Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP1-2">• Total Other Needs Assistance Approved Amount (Aggregated Eligibility Amount) Total Other Needs Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP1-2">• Total Personal Property Assistance Amount (Aggregated Eligibility Amount) Total Personal Property Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Repair Assistance Approved Amount (Aggregated Eligibility Amount) Total Repair Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP1-2">• Total Replacement Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP1-2">• Community Number (NFIP)</FP>
                <FP SOURCE="FP1-2">• Community Name (NFIP)</FP>
                <FP SOURCE="FP1-2">• Policy Number (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insurance Company Number (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insurance Company Name (NFIP)</FP>
                <FP SOURCE="FP1-2">• Policy Holder First Name (NFIP)</FP>
                <FP SOURCE="FP1-2">• Policy Holder Last Name (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property Address 1 (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property Address 2 (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property City (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property State (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property Zip Code (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property Zip Cod +4 (NFIP)</FP>
                <FP SOURCE="FP1-2">• Occupancy Type (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Property County (NFIP)</FP>
                <FP SOURCE="FP1-2">
                    • Post FIRM (NFIP)
                    <PRTPAGE P="8698"/>
                </FP>
                <FP SOURCE="FP1-2">• Building Type (NFIP)</FP>
                <FP SOURCE="FP1-2">• Date of Loss (NFIP)</FP>
                <FP SOURCE="FP1-2">• Building Payment (NFIP)</FP>
                <FP SOURCE="FP1-2">• Contents Payment (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Building Longitude (NFIP)</FP>
                <FP SOURCE="FP1-2">• Insured Building Latitude (NFIP)</FP>
                <FP SOURCE="FP1-2">• Geocode Accuracy (NFIP)</FP>
                <FP SOURCE="FP1-2">• Repetitive Loss (FMA) (NFIP)</FP>
                <FP SOURCE="FP1-2">• Severe Repetitive Loss</FP>
                <FP SOURCE="FP1-2">• Repetitive Loss Number (NFIP)</FP>
                <FP SOURCE="FP1-2">• Storm ID (NFIP)</FP>
                <FP SOURCE="FP1-2">• Storm Name (NFIP)</FP>
                <FP SOURCE="FP1-2">• Last Refresh Date (NFIP)</FP>
                <P>
                    <E T="03">System(s) of Records:</E>
                </P>
                <P>• DHS/FEMA-008 Disaster Recovery Assistance Files System of Records Notice, 87 FR 7852 (February 10, 2022), or as amended.</P>
                <P>• Tenant Rental Assistance Certification System, TRACS (HSNG/MF.HTS.02) 88 FR 62813 (September 13, 2023)</P>
                <P>• Inventory Management System (also known as the Public and Indian Housing Information Center) (IMS/PIC), HUD/PIH.01, 88 FR 66037 (September 26, 2023).</P>
                <P>• Enterprise Income Verification (EIV), HUD/PIH-5, 87 FR 50635 (August 17, 2022).</P>
                <SIG>
                    <NAME>Bradley S. Jewitt,</NAME>
                    <TITLE>Senior Agency Official for Privacy, Department of Housing &amp; Urban Development.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02567 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4210-67-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No. FR-7092-N-16]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; Matching Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Administration, Department of Housing and Urban Development (HUD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of new matching program.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to the Privacy Act of 1974, as amended by the Computer Matching and Privacy Act of 1988 and the Computer Matching and Privacy Protections Amendment of 1990 (Privacy Act), and Office of Management and Budget (OMB) guidance on the conduct of matching programs, notice is hereby given of the establishment of a matching program between the U.S. Department of Housing and Urban Development (HUD) and the State of Missouri, the State of Oklahoma, the State of New Jersey, the State of Pennsylvania, the State of New York, the State of Oregon, and the Commonwealth of Puerto Rico.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Please submit comments on or before March 11, 2024. The matching program will be effective on March 11, 2024 unless comments have been received from interested members of the public that require modification and republication of the notice. The matching program will continue for 18 months from the beginning date and may be extended an additional 12 months if the conditions specified in 5 U.S.C. 552a(o)(2)(D) have been met.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit comments regarding this notice at 
                        <E T="03">www.regulations.gov</E>
                         or to the Rules Docket Clerk, Office of General Counsel, Department of Housing and Urban Development, 451 Seventh Street SW, Room 10110, Washington, DC 20410. Communications should refer to the above docket number. A copy of each communication submitted will be available for public inspection and copying between 8:00 a.m. and 5:00 p.m. weekdays at the above address.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To obtain additional information about this matching program and the contents of this Computer Matching Agreement between HUD and the State of Missouri, the State of Oklahoma, the State of New Jersey, the State of Pennsylvania, the State of New York, the State of Oregon, and the Commonwealth of Puerto Rico, please view this Computer Matching Agreement at the following website: 
                        <E T="03">https://www.hud.gov/program_offices/officeofadministration/privacy_act/cma.</E>
                    </P>
                    <P>
                        For general questions about this matching program, contact Tennille Smith Parker, Director, Office of Disaster Recovery, U.S. 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 and communication disabilities. To learn more about how to make an accessible telephone call, please visit: 
                        <E T="03">https://www.fcc.gov/consumers/guides/telecommunications-relay-service-trs.</E>
                         Facsimile inquiries may be sent to Ms. Parker at 202-708-0033. (Except for the “800” number, these telephone numbers are not toll-free.) Email inquiries may be sent to 
                        <E T="03">disaster_recovery@hud.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>HUD is providing this notice in accordance with the Privacy Act of 1974 (5 U.S.C. 552a), as amended by the Computer Matching and Privacy Protection Act of 1988 (Pub. L. 100-503) and the Computer Matching and Privacy Protection Amendments of 1990 (Pub. L. 101-508) (Privacy Act); Office of Management and Budget (OMB) Final Guidance Interpreting the Provisions of Public Law 100-503, the Computer Matching and Privacy Protection Act of 1988, 54 FR 25818 (June 19, 1989); and OMB Circular A-108, 81 FR 94424 (December 23, 2016).</P>
                <P>To support the prevention and detection of duplication of benefits, HUD will request data from FEMA on an as-needed basis to share with Community Development Block Grant disaster recovery (CDBG-DR) grantees, and the grantees will use the data to detect and prevent the duplication of benefits. CDBG-DR grantees will conduct a duplication of benefits review for CDBG-DR grant-funded programs and activities. HUD's data request will be based on the specific program requirements specified in an approved CDBG-DR grantee action plan. CDBG-DR grantees will use FEMA data received through HUD to facilitate expedited program implementation while preventing the duplication of benefits already received from FEMA. All data sharing from HUD to CDBG-DR grantees will occur in accordance with agreements between HUD and the CDBG-DR grantees that address requirements related to the use and protection of the data.</P>
                <P>
                    <E T="03">Participating Agencies:</E>
                     U.S. Department of Housing and Urban Development (HUD), the State of Missouri, the State of Oklahoma, the State of New Jersey, the State of Pennsylvania, the State of New York, the State of Oregon, and the Commonwealth of Puerto Rico.
                </P>
                <P>
                    <E T="03">Authority for Conducting the Matching Program:</E>
                </P>
                <P>
                    A. Robert T. Stafford Disaster Relief and Emergency Assistance Act (as amended at 42 U.S.C. 5155(a) 
                    <E T="03">et seq.</E>
                    ) (Stafford Act), section 312, which requires each Federal agency that administers any program providing financial assistance because of a major disaster or emergency to assure that no individual or entity receives duplicate financial assistance under any program, from insurance, or through any other source. The Stafford Act, 42 U.S.C. 5155(c), requires FEMA or HUD (whichever agency provided the duplicative assistance) to recover all duplicative assistance from the recipient when the head of such agency considers it to be in the best interest of the Federal Government.
                </P>
                <P>
                    B. Section 408(i) of the Stafford Act, 42 U.S.C. 5174(i), directs and authorizes FEMA, in carrying out section 408 (Federal Assistance to Individuals and Households), to “develop a system, including an electronic database,” to: (a) Verify the identity and address of recipients of assistance to provide reasonable assurance that payments are 
                    <PRTPAGE P="8699"/>
                    made only to an individual or household that is eligible for such assistance, (b) Minimize the risk of making duplicative payments or payments for fraudulent claims, (c) Collect any duplicate payment on a claim or reduce the amount of subsequent payments to offset the amount of any such duplicate payment, (d) Provide instructions to recipients of assistance regarding the proper use of any such assistance, regardless of how such assistance is distributed, and (e) Conduct an expedited and simplified review and appeal process for an individual or household whose application for assistance is denied.
                </P>
                <P>C. HUD imposes the requirements of the Stafford Act, section 312, on CDBG-DR grantees. Appropriations acts making CDBG-DR funds available, as listed in section II.C.8 of the Computer Matching Agreement, require CDBG-DR grantees to have adequate procedures to prevent the duplication of benefits. HUD enforces these requirements on CDBG-DR grantees using its statutory and regulatory remedies for noncompliance in section 111 of title I of the Housing and Community Development of 1974 (42 U.S.C. 5311) and regulations at 24 CFR part 570 and 2 CFR part 200.</P>
                <P>D. Executive Order 13411, “Improving Assistance for Disaster Victims,” 71 FR 52729 (August 29, 2006), calls on Federal agencies to “reduce unnecessarily duplicative application forms and processes for Federal disaster assistance,” which includes processing benefits applications submitted by individuals, businesses, or other entities for the same disaster.</P>
                <P>E. The President may authorize both emergency sheltering and section 408 Federal assistance to individuals and households, pursuant to either a major disaster under section 403, at 42 U.S.C. 5170b, or an emergency under section 502 of the Stafford Act, 42 U.S.C. 5192. Essential Assistance, pursuant to section 403(a)(3)(B) of the Stafford Act, 42 U.S.C. 5170b, authorizes emergency sheltering, including both congregate and non-congregate sheltering, to meet the immediate needs of disaster survivors for a major disaster. Additionally, Federal assistance where necessary to prevent human suffering under section 502(a)(8) authorizes emergency sheltering for an emergency.</P>
                <P>F. The Debt Collection Improvement Act of 1996, 31 U.S.C. 3325(d) and 7701(c)(1), which requires federal agencies to collect the Taxpayer Identification Number (TIN) or Social Security Number (SSN) of each person who receives payments from the Federal Government; and each person doing business with the Federal Government is required to furnish his or her TIN. For the purposes of 31 U.S.C. 7701, a person is doing business with the Federal Government if the person is: (1) A lender or servicer in a Federal guaranteed or insured loan program administered by a Federal agency, (2) An applicant for, or recipient of, a Federal license permit, right-of-way, grant, or benefit payment administered by a Federal agency, (3) A contractor of a Federal agency, (4) Assessed a fine, fee, royalty, or penalty by a Federal agency, or (5) In a relationship with a Federal agency that may give rise to a receivable due to that agency such as a partner of a borrower in or a guarantor of a Federal direct or insured loan administered by the Federal agency. Each Federal agency must inform each person required to disclose his or her TIN of the agency's intent to use such number for purposes of collecting and reporting on any delinquent amounts arising out of such person's relationship with the Federal Government.</P>
                <P>G. The appropriations acts that authorize and appropriate supplemental CDBG-DR assistance lay out specific requirements, some of which may vary by appropriation. These appropriations acts impose requirements related to the (1) prevention of fraud, waste, and abuse, (2) order of assistance, and (3) prevention of duplication of benefits on HUD or its CDBG-DR grantees, as directed by the applicable act. The appropriations acts, listed below, also require HUD to make allocations based on a determination of unmet need in the “most impacted and distressed areas” resulting from major disasters.</P>
                <P>
                    Legal authority for CDBG-DR assistance is derived from title I of the Housing and Community Development Act of 1974 (42 U.S.C. 5301 
                    <E T="03">et seq.</E>
                    ); subsequent appropriations acts making CDBG-DR assistance available; the following prior appropriations acts—Public Law 117-328, 117-180, 117-43, 116-20, 115-254, 115-123, 115-56, 115-31, 114-254, 114-223, 114-113, 113-2, 112-55, 111-212, 110-329, 110-252, 110-116, 109-234, 109-148, 108-324, 107-206, 107-117, 107-73, 107-38, 106-31, 105-277, 105-276, 105-174, 105-18, 104-134, 104-19, 103-327, 103-211, 103-75, and 103-50-and by the notices published in the 
                    <E T="04">Federal Register</E>
                     that govern CDBG-DR grant assistance including the 
                    <E T="03">Updates to Duplication of Benefits Requirements Under the Stafford Act for Community Development Block Grant (CDBG) Disaster Recovery Grantees</E>
                     at 84 FR 28836 (June 20, 2019).
                </P>
                <P>H. The HUD regulation at 24 CFR 982.352(c) prohibits a family from receiving the benefit of section 8 tenant-based assistance under the Housing Choice Voucher Program while also receiving the benefit of any of the following forms of other housing subsidy for the same or a different unit:</P>
                <P>1. Public or Indian housing assistance,</P>
                <P>2. Section 8 assistance (including other tenant-based assistance) under section 8 of the U.S. Housing Act of 1937, 42 U.S.C. 1437f,</P>
                <P>3. Assistance under former section 23 of the United States Housing Act of 1937 (before amendment by the Housing and Community Development Act of 1974),</P>
                <P>4. Section 101 of the Housing and Urban Development Act of 1965, 12 U.S.C.1701s (section 101 rent supplements),</P>
                <P>5. Section 236 of the National Housing Act, 12 U.S.C.1715z-1 (section 236 rental assistance payments),</P>
                <P>
                    6. Tenant-based assistance under the HOME Investment Partnerships Program (HOME) authorized by Title II of the Cranston-Gonzalez National Affordable Housing Act, 42 U.S.C. 12701 
                    <E T="03">et seq.,</E>
                </P>
                <P>
                    7. Rental assistance payments under section 521 of the Housing Act of 1949, 42 U.S.C. 258 1441 
                    <E T="03">et seq.</E>
                     (a program of the Rural Development Administration),
                </P>
                <P>8. Any local or State rent subsidy,</P>
                <P>9. Section 202 of the Housing Act of 1959, 12 U.S.C. 1701q, as amended (section 202 supportive housing for the elderly),</P>
                <P>10. Section 811 of the Cranston-Gonzalez National Affordable Housing Act, as amended, 42 U.S.C. 8013 (section 811 supportive housing for persons with disabilities),</P>
                <P>11. Section 202 projects for non-elderly persons with disabilities (section 162 assistance) authorized by section 162 of the Housing and Community Development Act of 1987, 12 U.S.C. 1701a note, amending section 202(h) of the Housing Act of 1959, or</P>
                <P>12. Any other duplicative Federal, State, or local housing subsidy, as determined by HUD. For this purpose, “housing subsidy” does not include the housing component of a welfare payment, a Social Security payment received by the family, or a rent reduction because of a tax credit. (June 20, 2019).</P>
                <P>
                    <E T="03">Purpose(s):</E>
                     The Computer Matching Agreements describe the respective responsibilities of HUD and the State of Missouri, the State of Oklahoma, the State of New Jersey, the State of Pennsylvania, the State of New York, the State of Oregon, and the Commonwealth of Puerto Rico to determine and verify the accuracy of the data, eligibility for their respective benefits, and to preserve the 
                    <PRTPAGE P="8700"/>
                    confidentiality of information in accordance with the matching program. The requirements of the Computer Matching Agreements will be carried out by authorized users of the State of Missouri, the State of Oklahoma, the State of New Jersey, the State of Pennsylvania, the State of New York, the State of Oregon, and the Commonwealth of Puerto Rico (which include the grantees' authorized employees, and contractors). The agreements also describe the responsibilities of HUD, HUD's CDBG-DR grantees, and DHS-FEMA for other purposes, as described below.
                </P>
                <P>The Computer Matching Agreements establish the terms and conditions governing the CDBG-DR grantees access to, and use of FEMA's Individual Assistance (IA), Individual's and Household Program data. HUD will request data from FEMA on an as-needed basis. FEMA will perform data analysis and generate a file for HUD. All FEMA program data that HUD provides to CDBG-DR grantees will be shared via these Computer Matching Agreements between HUD and CDBG-DR grantees that reflect the requirements of an existing Computer Matching Agreement between FEMA and HUD. The data exchanged between HUD and CDBG-DR grantees will be used to support the duplication of benefits checks conducted by the grantee. There is an existing Computer Matching Agreement between FEMA and HUD that establishes the terms and conditions governing HUD's access to FEMA's Individual Assistance (IA), Individual's and Household Program data.</P>
                <P>HUD will provide FEMA data to CDBG-DR grantees, pursuant to their separate Computer Matching Agreements, for them to use to determine the correct award amount for eligible program beneficiaries by identifying unmet needs of FEMA applicants; prevent the duplication of benefits; implement the statutory requirement that CDBG-DR funds may not be used for activities reimbursable by or for which funds are made available by FEMA; and implement the statutory requirement to establish procedures to detect and prevent waste, fraud, and abuse of funds.</P>
                <P>
                    <E T="03">Categories of Individuals:</E>
                     DHS/FEMA data in this matching program includes individuals that have applied for or expressed interest in disaster assistance. HUD provides the FEMA data to grantees in this matching program for the verification of individuals who have applied for or received assistance via HUD assistance programs.
                </P>
                <P>
                    <E T="03">Categories of Records:</E>
                     Data elements disclosed by each agency in this matching program are as follows:
                </P>
                <P>A. From DHS/FEMA to HUD:</P>
                <FP SOURCE="FP-1">• Name (First and Last of Applicant and Co-applicant)</FP>
                <FP SOURCE="FP-1">• Date of Birth (Applicant and Co-Applicant)</FP>
                <FP SOURCE="FP-1">• Social Security Number (last 4 of Applicant and Co-applicant)</FP>
                <FP SOURCE="FP-1">• Phone Number (Applicant Alternate Phone Number, Applicant Current Phone Number, Co-applicant Current Phone Number)</FP>
                <FP SOURCE="FP-1">• Email Address of Applicant</FP>
                <FP SOURCE="FP-1">• Applicant Registration Number</FP>
                <FP SOURCE="FP-1">• Current Mailing Address (Street, City, County, State, Zip Code)</FP>
                <FP SOURCE="FP-1">• Current Location (as identified in applicant registration and applicant information screen)</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Latitude and Longitude</FP>
                <FP SOURCE="FP-1">• Damaged Address (Street, City, County, State, Zip Code + 4 Digit Ext.)</FP>
                <FP SOURCE="FP-1">• Access and Functional Needs (Y/N)</FP>
                <FP SOURCE="FP-1">• Household Member Age Range (Under 5 years, 5 to 17 years, 18 to 64 years, 65 and above)</FP>
                <FP SOURCE="FP-1">• Number of Household Members</FP>
                <FP SOURCE="FP-1">• Number of Dependents in Household</FP>
                <FP SOURCE="FP-1">• Current Hotel (Name, Address, City, County)</FP>
                <FP SOURCE="FP-1">• Initial Rental Assistance Approved Date</FP>
                <FP SOURCE="FP-1">• Direct Housing First Licensed-In Date</FP>
                <FP SOURCE="FP-1">• Last Continued Temporary Housing Assistance Date</FP>
                <FP SOURCE="FP-1">• Small Business Administration (SBA) HAPP Referral Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Census Block Group ID (if applicable)</FP>
                <FP SOURCE="FP-1">• Cause(s) of Damage from Inspection</FP>
                <FP SOURCE="FP-1">• Destroyed Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Disaster Number</FP>
                <FP SOURCE="FP-1">• Flood Zone</FP>
                <FP SOURCE="FP-1">• High Water Mark Location</FP>
                <FP SOURCE="FP-1">• High Water Depth in Inches</FP>
                <FP SOURCE="FP-1">• Habitability Repairs Required (Y/N)</FP>
                <FP SOURCE="FP-1">• Gross Income (as reported at Registration)</FP>
                <FP SOURCE="FP-1">• Insurance Types (Insurance Code)</FP>
                <FP SOURCE="FP-1">• Level of Damage</FP>
                <FP SOURCE="FP-1">• Owner/Renter</FP>
                <FP SOURCE="FP-1">• Personal Property Total FEMA Verified Loss (FVL) Amount</FP>
                <FP SOURCE="FP-1">• Personal Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP-1">• Real Property Total FVL Amount (Aggregated for all REAL PROPERTY FVL)</FP>
                <FP SOURCE="FP-1">• Real Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP-1">• Residence Type</FP>
                <FP SOURCE="FP-1">• FEMA Inspection Completed (Y/N)</FP>
                <FP SOURCE="FP-1">• Primary Residence (RI) (Yes/No)</FP>
                <FP SOURCE="FP-1">• Household Member Age and Name (First and Last)</FP>
                <FP SOURCE="FP-1">• Insurance Settlement Flood Amount</FP>
                <FP SOURCE="FP-1">• Insurance Settlement Other Amount</FP>
                <FP SOURCE="FP-1">• Non-Compliant with Flood Insurance Requirement NCOMP Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Temporary Housing Unit (THU)—Latest Currently Licensed-In Date</FP>
                <FP SOURCE="FP-1">• Total Housing Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-1">• Total Housing Assistance Approved Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Other Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-1">• Total Other Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP-1">• Total Other Needs Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-1">• Total Other Needs Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP-1">• Total Personal Property Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-1">• Total Personal Property Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Repair Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <FP SOURCE="FP-1">• Total Repair Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Replacement Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <P>B. From HUD to HUD Grantee:</P>
                <FP SOURCE="FP-1">• Alternate Current Contact Phone Number</FP>
                <FP SOURCE="FP-1">• SBA Referral Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Co-registrant Date of Birth</FP>
                <FP SOURCE="FP-1">• Co-registrant First Name</FP>
                <FP SOURCE="FP-1">• Co-registrant Last Name</FP>
                <FP SOURCE="FP-1">• Co-registrant SSN</FP>
                <FP SOURCE="FP-1">• Current Contact Phone Number</FP>
                <FP SOURCE="FP-1">• Current Location</FP>
                <FP SOURCE="FP-1">• Current Mailing 5 Digit Zip Code</FP>
                <FP SOURCE="FP-1">• Current Mailing Address City</FP>
                <FP SOURCE="FP-1">• Current Mailing Address Street</FP>
                <FP SOURCE="FP-1">• Current Mailing State</FP>
                <FP SOURCE="FP-1">• Current Mailing Zip 4 Digit Extension</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Address County</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Latitude</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Longitude</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Address 5 Digit Zip Code</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Address City</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Address Street</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling State</FP>
                <FP SOURCE="FP-1">• Damaged Dwelling Zip Code 4 Digit Extension</FP>
                <FP SOURCE="FP-1">• Dependents (Number in Household)</FP>
                <FP SOURCE="FP-1">• Destroyed Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Disaster Number</FP>
                <FP SOURCE="FP-1">• FEMA Inspection Completed (Y/N)</FP>
                <FP SOURCE="FP-1">• FEMA Registration Number</FP>
                <FP SOURCE="FP-1">• Flood Zone</FP>
                <FP SOURCE="FP-1">• Gross Income</FP>
                <FP SOURCE="FP-1">• High Water Mark Location</FP>
                <FP SOURCE="FP-1">• High Water Depth in Inches</FP>
                <FP SOURCE="FP-1">
                    • Household Member Age
                    <PRTPAGE P="8701"/>
                </FP>
                <FP SOURCE="FP-1">• Household Member First Name</FP>
                <FP SOURCE="FP-1">• Household Member Last Name</FP>
                <FP SOURCE="FP-1">• Inspection Completion(Y/N)</FP>
                <FP SOURCE="FP-1">• Insurance Settlement Flood Amount</FP>
                <FP SOURCE="FP-1">• Insurance Settlement Other Amount</FP>
                <FP SOURCE="FP-1">• Insurance Type (Insurance Code)</FP>
                <FP SOURCE="FP-1">• NCOMP Flag (Y/N)</FP>
                <FP SOURCE="FP-1">• Owner/Renter</FP>
                <FP SOURCE="FP-1">• Personal Property Total FVL Amount (Aggregated for all PERSONAL PROPERTY FVL one field replaces all fields related to personal property damage) Personal Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP-1">• Primary Residence (RI) (Yes/No)</FP>
                <FP SOURCE="FP-1">• Real Property Total FVL Amount (Aggregated for all REAL PROPERTY FVL (one field replaces all fields related to real property damage) Real Property Flood Damage FVL Amount</FP>
                <FP SOURCE="FP-1">• Registrant Date of Birth</FP>
                <FP SOURCE="FP-1">• Registrant First Name</FP>
                <FP SOURCE="FP-1">• Registrant Last 4 Digits of SSN</FP>
                <FP SOURCE="FP-1">• Registrant Last Name</FP>
                <FP SOURCE="FP-1">• Residence Type</FP>
                <FP SOURCE="FP-1">• Temporary Housing Unit (THU)—Latest Currently Licensed-in Date</FP>
                <FP SOURCE="FP-1">• Total Housing Assistance Approved Amount (Aggregated Eligibility Amount) Total Housing Assistance Approved Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Other Assistance Approved Amount (Aggregated Eligibility Amount) Total Other Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP-1">• Total Other Needs Assistance Approved Amount (Aggregated Eligibility Amount) Total Other Needs Assistance Flood Damage Approved Amount</FP>
                <FP SOURCE="FP-1">• Total Personal Property Assistance Amount (Aggregated Eligibility Amount) Total Personal Property Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Repair Assistance Approved Amount (Aggregated Eligibility Amount) Total Repair Assistance Flood Damage Amount</FP>
                <FP SOURCE="FP-1">• Total Replacement Assistance Approved Amount (Aggregated Eligibility Amount)</FP>
                <P>
                    <E T="03">System(s) of Records:</E>
                </P>
                <FP SOURCE="FP-1">• DHS/FEMA-008 Disaster Recovery Assistance Files System of Records Notice, 87 FR 7852 (February 10, 2022), or as amended.</FP>
                <FP SOURCE="FP-1">• Inventory Management System (also known as the Public and Indian Housing Information Center) (IMS/PIC), HUD/PIH.01, 84 FR 11117 (March 25, 2019).</FP>
                <FP SOURCE="FP-1">• Enterprise Income Verification (EIV), HUD/PIH-5, EIV 71 FR 45,066 (August 8, 2006), which was updated by 74 FR 45235 (September 1, 2009). Tenant Rental Assistance Certification System (TRACS), HSNG/MF.HTS.02, 81 FR 56684 (August 22, 2016).</FP>
                <SIG>
                    <NAME>Bradley S. Jewitt,</NAME>
                    <TITLE>Senior Agency Official for Privacy, Department of Housing &amp; Urban Development.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02566 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4210-67-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No: FR-7092-N-19]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; Matching Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Real Estate Assessment Center, Office of Public and Indian Housing, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a re-established matching program.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to the Computer Matching and Privacy Protection Act of 1988, as amended, HUD is providing notice of its intent to execute a new computer matching agreement with HHS for a recurring matching program with HUD's Office of Public and Indian Housing (PIH) and Office of Housing, involving comparisons of information provided by participants in any authorized HUD rental housing assistance program with the independent sources of income information available through the National Directory of New Hires (NDNH) maintained by HHS. HUD will obtain HHS data and make the results available to: (1) Program administrators such as public housing agencies (PHAs) and private owners and management agents (O/As) (collectively referred to as POAs) to enable them to verify the accuracy of income reported by the tenants (participants) of HUD rental assistance programs and (2) contract administrators (Cas) overseeing and monitoring O/A operations as well as independent public auditors (IPAs) that audit both PHAs and O/As. The most recent renewal of the current matching agreement expires on February 28, 2024.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The period of this matching program is estimated to cover the 18-month period from February 28, 2024, through August 28, 2025. However, the computer matching agreement (CMA) will become applicable at the later of the following two dates: February 28, 2024, or 30 days after all public comments have been received from interested members of the public requiring modification to the notice and republication of the notice for another 30-day comment period. The matching program will continue for 18 months after the applicable date and may be extended for an additional 12 months, if the respective agency Data Integrity Boards (DIBs) determine that the conditions specified in 5 U.S.C. 552a(o)(2)(D) have been met.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit comments regarding this notice at 
                        <E T="03">www.regulations.gov</E>
                         or to the Rules Docket Clerk, Office of General Counsel, Department of Housing and Urban Development, 451 Seventh Street SW, Room 10276, Washington, DC 20410. Communications should refer to the above docket number A copy of each communication submitted will be available for public inspection and copying between 8:00 a.m. and 5:00 p.m. weekdays at the above address.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Contact the Recipient Agency.</P>
                    <P>
                        Bradley S. Jewitt, Senior Agency Official for Privacy, Department of Housing and Urban Development, 451 Seventh Street SW, Room 6204, Washington, DC 20410, telephone number (202) 402-5522. HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech and communication disabilities. To learn more about how to make an accessible telephone call, please visit: 
                        <E T="03">https://www.fcc.gov/consumers/guides/telecommunications-relay-service-trs.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Pursuant to the Computer Matching and Privacy Protection Act (CMPPA) of 1988, as amended; OMB's guidance on this statute entitled, “Final Guidance Interpreting the Provisions of Public Law 100-503”; OMB Circular No. A-108, “Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act;” and OMB Circular No. A-130, “Managing Information as a Strategic Resource”; HUD is providing the public with notice of a new computer matching agreement with HHS (previous notice of a computer matching program between HUD and HHS was previously published at 86 FR 40610 on July 28, 2021). The first HUD-HHS computer matching program was conducted in September 2005, with HUD's Office of Public and Indian Housing. The scope of the HUD-HHS computer matching program was extended to include HUD's Office of Housing in December 2007, and the participants of HUD's Disaster Housing Assistance Program (DHAP) in January 2011.</P>
                <P>
                    The matching program will be carried out only to the 'xtent necessary to: (1) verify the employment and income of participants in certain rental assistance programs to correctly determine the 
                    <PRTPAGE P="8702"/>
                    amount of their rent and assistance, (2) identify, prevent, and recover improper payments made on behalf of tenants, and (3) after removal of personal identifiers, to conduct analyses of the employment and income reporting of individuals participating in any HUD authorized rental housing assistance program.
                </P>
                <P>HUD will make the results of the computer matching program available to public housing agencies (PHAs), private housing owners and management agents (O/As) administering HUD rental assistance programs to enable them to verify employment and income and correctly determine the rent and assistance levels for individuals participating in those programs, and contract administrators (Cas) overseeing and monitoring O/A operations. This information also may be disclosed to the HUD Office of Inspector General (HUD/OIG) and the United States Attorney General in detecting and investigating potential cases of fraud, waste, and abuse within HUD rental assistance programs.</P>
                <P>
                    In addition to the above noted information disclosures, limited redisclosure of reports containing NDNH information may be redisclosed to the following persons and/or entities: (1) Independent auditors for the sole purpose of performing an audit of whether these HUD authorized entities verified tenants' employment and/or income and calculated the subsidy and rent correctly; and (2) entities and/or individuals associated with grievance procedures and judicial proceedings (
                    <E T="03">i.e.,</E>
                     lawyers, court personnel, agency personnel, grievance hearing officers, etc.) relating to independently verified unreported income identified through this matching program.
                </P>
                <P>HUD and its third-party administrators (PHAs, O/As, and CAs) will use this matching authority to identify, reduce or eliminate improper payments in HUD's rental housing assistance programs, while continuing to ensure that HUD rental housing assistance programs serve and are accessible by its intended program beneficiaries.</P>
                <P>
                    <E T="03">Participating Agencies:</E>
                     Department of Housing and Urban Development and the Department of Health and Human Services.
                </P>
                <P>
                    <E T="03">Authority for Conducting the Matching Program:</E>
                     This matching program is being conducted pursuant to Section 217 of the Consolidated Appropriation Act of 2004 (Pub. L. 108-199, Approved January 23, 2004), which amended Section 453(j) of the Social Security Act (42 U.S.C. 653
                    <E T="03">(j)</E>
                    ), Sections 3003 and 13403 of the Omnibus Budget Reconciliation Act of 1993 (Pub. L. 103-66, approved August 10, 1993); Section 542(b) of the 1998 Appropriations Act (Pub. L. 105-65); Section 904 of the Stewart B. McKinney Homeless Assistance Amendments Act of 1988, as amended by Section 239 of HUD's 2009 Appropriations, effective March 11, 2009 (42 U.S.C. 3544); Section 165 of the Housing and Community Development Act of 1987 (42 U.S.C. 3543); the National Housing Act (12 U.S.C. 1701-
                    <E T="03">1750g</E>
                    ); the United States Housing Act of 1937 (42 U.S.C. 1437-
                    <E T="03">1437z</E>
                    ); Section 101 of the Housing and Community Development Act of 1965 (12 U.S.C. 1701
                    <E T="03">s</E>
                    ); the Native American Housing Assistance and Self-Determination Act of 1996 (25 U.S.C. 4101 
                    <E T="03">et seq.</E>
                    ); and the Quality Housing and Work Responsibility Act of 1998 (42 U.S.C. 1437
                    <E T="03">a(f)</E>
                    ).
                </P>
                <P>The Housing and Community Development Act of 1987 authorizes HUD to require applicants and participants (as well as members of their household 6 years of age and older) in HUD-administered programs involving rental housing assistance to disclose to HUD their Social Security Numbers (SSNs) as a condition of initial or continuing eligibility for participation in the programs. Effective January 31, 2010, all applicants and participants under the age of 6, are required to disclose their SSN to HUD, in accordance with regulatory revisions made to 24 CFR 5.216, as published at 74 FR 68924, on December 29, 2009.</P>
                <P>Section 217 of the Consolidated Appropriations Act of 2004 (Pub. L. 108-199, approved January 23, 2004) authorizes HUD to provide to HHS information on persons participating in any programs authorized by:</P>
                <P>
                    (i) The United States Housing Act of 1937 (42 U.S.C. 1437 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    (ii) Section 202 of the Housing Act of 1959 (12 U.S.C. 1701
                    <E T="03">q</E>
                    );
                </P>
                <P>
                    (iii) Section 221(d)(3), 221(d)(5) or 236 of the National Housing Act (12 U.S.C. 17151
                    <E T="03">(d)</E>
                     and 
                    <E T="03">1715z-1</E>
                    ); (iv) Section 811 of the Cranston-Gonzalez National Affordable Housing Act (42 U.S.C. 8013); or (v) Section 101 of the Housing and Urban Development Act of 1965 (12 U.S.C. 1701
                    <E T="03">s</E>
                    );
                </P>
                <P>The Refinement of Income and Rent Determination Requirements in Public and Assisted Housing Programs: Implementation of the Enterprise Income Verification (EIV) System—Amendments; Final rule published at 74 FR 68924 on December 29, 2009, requires program administrators to use HUD's EIV system to verify tenant employment and income information during mandatory re-examinations or recertifications of family composition and income and reduce administrative and subsidy payment errors in accordance with HUD administrative guidance (HUD regulation at 24 CFR 5.233).</P>
                <P>This matching program also assists HUD in complying with the following Federal laws, requirements, and guidance related to identifying and reducing improper payments:</P>
                <P>1. Improper Payments Elimination and Recovery Act of 2010 (IPERA) (Pub. L. 111-204) (July 22, 2010);</P>
                <P>2. Presidential Memorandum on Enhancing Payment Accuracy Through a “Do Not Pay List” (June 18, 2010)</P>
                <P>3. Office of Management and Budget M-18-20, Transmittal of Appendix C to OMB Circular A-123, Requirements for Payment Integrity Improvement” (June 26, 2018);</P>
                <P>4. Presidential Memorandum on Finding and Recapturing Improper Payments (March 10, 2010);</P>
                <P>5. Reducing Improper Payments and Eliminating Waste in Federal Programs (Executive Order 13520, November 2009);</P>
                <P>6. Improper Payments Information Act of 2002 (Pub. L. 107-300);</P>
                <P>7. Office of Management and Budget M-03-13, Improper Payments Information Act of 2002;</P>
                <P>8. Improper Payments Elimination and Recovery Improvement Act (IPERIA) of 2012, (Pub. L. 112-248) (January 10, 2013); and</P>
                <P>9. Office of Management and Budget M-13-20, Protecting Privacy while Reducing Improper Payments with the Do Not Pay Initiative (August 16, 2013).</P>
                <P>This matching program is also authorized by subsections 453(j)(7)(A), (C)(i), and (D)(i) of the Social Security Act (as amended and authorized by Section 217 of the Consolidated Appropriations Act of 2004 (Pub. L. 108-199)). Specifically, the aforementioned law authorizes HHS to compare information provided by HUD with data contained in the NDNH and report the results of the data match to HUD. The Social Security Act gives HUD the authority to disclose this information to CAs, O/As, and PHAs for the purpose of verifying the employment and income of individuals receiving benefits in the above programs. HUD shall not seek, use or disclose information relating to an individual without the prior written consent of that individual, and HUD has the authority to require consent as a condition of participating in HUD rental housing assistance programs.</P>
                <P>
                    The NDNH contains new hire, quarterly wage, and unemployment insurance information furnished by State and Federal agencies and is 
                    <PRTPAGE P="8703"/>
                    maintained by HHS' Office of Child Support Enforcement (OCSE) in its system of records “OCSE National Directory of New Hires,” No. 09-80-0381, published in the 
                    <E T="04">Federal Register</E>
                     at 80 FR 17894 (specifically pages 17906-17909) on April 2, 2015. The published system of records notice authorizes disclosure of NDNH information to HUD pursuant to Routine Use (12) “for the purpose of verifying the employment and income of the individuals and, after removal of personal identifiers, for the purpose of conducting analyses of the employment and income reporting of such individuals.”
                </P>
                <P>
                    The HUD records used in the information comparison are retrieved from HUD's Enterprise Income Verification (EIV) System, and the results of the information comparison are maintained within HUD's EIV System No. HUD/PIH-5, last published in the 
                    <E T="04">Federal Register</E>
                     at 87 FR 50635(August 17, 2022). Routine use (D) of the system of records authorizes disclosure of HUD records to HHS.
                </P>
                <P>
                    <E T="03">Purpose(s):</E>
                     HUD's primary objective of the computer matching program is to verify the employment and income of participants in certain rental assistance programs to determine the appropriate level of rental assistance, and to detect, deter and correct fraud, waste, and abuse in rental housing assistance programs. In meeting these objectives, HUD also is carrying out a responsibility under 42 U.S.C. 1437f(K) to ensure that income data provided to PHAs, and O/As, by household members is complete and accurate. HUD's various rental housing assistance programs require that participants meet certain income and other criteria to be eligible for rental assistance. In addition, tenants generally are required to report and recertify the amounts and sources of their income at least annually. However, under the Quality Housing and Work Responsibility Act (QHWRA) of 1998, PHAs operating Public Housing programs may offer tenants the option to pay a flat rent, or an income-based rent. Those tenants who select a flat rent will be required to recertify income at least every three years. In addition, the changes to the Admissions and Occupancy final rule (March 29, 2000 (65 FR 16692)) specified that household composition must be recertified annually for tenants who select a flat rent or income-based rent.
                </P>
                <P>
                    <E T="03">Categories of Individuals:</E>
                </P>
                <HD SOURCE="HD3">Covered Programs</HD>
                <P>This notice of computer matching program applies to individuals receiving services from the following rental assistance programs:</P>
                <FP SOURCE="FP-2">A. Disaster Housing Assistance Program (DHAP)</FP>
                <FP SOURCE="FP-2">B. Public Housing</FP>
                <FP SOURCE="FP-2">C. Section 8 Housing Choice Vouchers (HCV)</FP>
                <FP SOURCE="FP-2">D. Project-Based Vouchers</FP>
                <FP SOURCE="FP-2">E. Section 8 Moderate Rehabilitation</FP>
                <FP SOURCE="FP-2">F. Project-Based Section 8</FP>
                <FP SOURCE="FP1-2">1. New Construction</FP>
                <FP SOURCE="FP1-2">2. State Agency Financed</FP>
                <FP SOURCE="FP1-2">3. Substantial Rehabilitation</FP>
                <FP SOURCE="FP1-2">4. Sections 202/8</FP>
                <FP SOURCE="FP1-2">5. Rural Housing Services Section 515/8</FP>
                <FP SOURCE="FP1-2">6. Loan Management Set-Aside (LMSA)</FP>
                <FP SOURCE="FP1-2">7. Property Disposition Set-Aside (PDSA)</FP>
                <FP SOURCE="FP-2">G. Section 101 Rent Supplement</FP>
                <FP SOURCE="FP-2">H. Section 202/162 Project Assistance Contract (PAC)</FP>
                <FP SOURCE="FP-2">I. Section 202 Project Rental Assistance Contract (PRAC)</FP>
                <FP SOURCE="FP-2">J. Section 811 Project Rental Assistance Contract (PRAC)</FP>
                <FP SOURCE="FP-2">K. Section 236 Rental Assistance Program</FP>
                <FP SOURCE="FP-2">L. Section 221(d)(3) Below Market Interest Rate (BMIR)</FP>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>This notice does not apply to the Low-Income Housing Tax Credit (LIHTC) or the Rural Housing Services Section 515 without Section 8 programs.</P>
                </NOTE>
                <P>
                    <E T="03">Categories of Records:</E>
                     The following are the categories of record in this matching agreement:
                </P>
                <FP SOURCE="FP-1">
                    <E T="03">HUD Input File</E>
                </FP>
                <FP SOURCE="FP-1">• First name</FP>
                <FP SOURCE="FP-1">• Last name</FP>
                <FP SOURCE="FP-1">• Date of birth</FP>
                <FP SOURCE="FP-1">• Social Security number</FP>
                <FP SOURCE="FP-1">
                    <E T="03">HHS New Hire File</E>
                </FP>
                <FP SOURCE="FP-1">• New hire processed date</FP>
                <FP SOURCE="FP-1">• Employee name</FP>
                <FP SOURCE="FP-1">• Employee address</FP>
                <FP SOURCE="FP-1">• Employee date of hire</FP>
                <FP SOURCE="FP-1">• Employee State of hire</FP>
                <FP SOURCE="FP-1">• Federal Employer Identification Number</FP>
                <FP SOURCE="FP-1">• State Employer Identification Number</FP>
                <FP SOURCE="FP-1">• Department of Defense status code</FP>
                <FP SOURCE="FP-1">• Employer name</FP>
                <FP SOURCE="FP-1">• Employer address</FP>
                <FP SOURCE="FP-1">• Transmitter agency code</FP>
                <FP SOURCE="FP-1">• Transmitter State code</FP>
                <FP SOURCE="FP-1">• Transmitter State or agency name</FP>
                <FP SOURCE="FP-1">
                    <E T="03">HHS Quarterly Wage File</E>
                </FP>
                <FP SOURCE="FP-1">• Quarterly wage processed date</FP>
                <FP SOURCE="FP-1">• Employee name</FP>
                <FP SOURCE="FP-1">• Federal Employer Identification Number</FP>
                <FP SOURCE="FP-1">• State Employer Identification Number</FP>
                <FP SOURCE="FP-1">• Department of Defense code</FP>
                <FP SOURCE="FP-1">• Employer name</FP>
                <FP SOURCE="FP-1">• Employer address</FP>
                <FP SOURCE="FP-1">• Employee wage amount</FP>
                <FP SOURCE="FP-1">• Quarterly wage reporting period</FP>
                <FP SOURCE="FP-1">• Transmitter agency code</FP>
                <FP SOURCE="FP-1">• Transmitter State code</FP>
                <FP SOURCE="FP-1">• Transmitter State or agency name</FP>
                <FP SOURCE="FP-1">
                    <E T="03">HHS Unemployment Insurance File</E>
                </FP>
                <FP SOURCE="FP-1">• Unemployment insurance processed date</FP>
                <FP SOURCE="FP-1">• Claimant name</FP>
                <FP SOURCE="FP-1">• Claimant address</FP>
                <FP SOURCE="FP-1">• Claimant benefit amount</FP>
                <FP SOURCE="FP-1">• Unemployment insurance reporting period</FP>
                <FP SOURCE="FP-1">• Transmitter State code</FP>
                <FP SOURCE="FP-1">• Transmitter State or agency name</FP>
                <P>
                    <E T="03">System(s) of Records:</E>
                     OCSE NDNH contains new hire, quarterly wage, and unemployment insurance information furnished by State and Federal agencies and is maintained by OCSE in its system of records “OCSE National Directory of New Hires,” No. 09-80-0381; see System of Records Notice (SORN) published in full at 87 FR 3550 (January 24, 2022). The disclosure of NDNH records by OCSS to HUD constitutes a “routine use,” as defined by the Privacy Act. 5 U.S.C. 552a(b)(3). Routine use (12) published in the NDNH SORN authorizes the disclosure of NDNH records to HUD. 87 FR 3553, 3555 (January 24, 2022).
                </P>
                <P>The HUD records used in the information comparison are retrieved from, and the results of the information comparison are maintained within, the HUD system of records “Enterprise Income Verification” (EIV), No. HUD/PIH-5, 87 FR 50635(August 17, 2022). Routine use (D) in that system of records authorizes the disclosure of HUD records to OCSE.</P>
                <SIG>
                    <NAME>Bradley S. Jewitt,</NAME>
                    <TITLE>Senior Agency Official for Privacy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02568 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4210-67-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Fish and Wildlife Service</SUBAGY>
                <DEPDOC>[Docket No. FWS-R8-ES-2023-0107; FF09M21200-234-FXMB1231099BPP0; OMB Control Number 1018-New]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Western Snowy Plover Survey and Reporting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In accordance with the Paperwork Reduction Act of 1995, we, the U.S. Fish and Wildlife Service (Service), are proposing a new information collection in use without 
                        <PRTPAGE P="8704"/>
                        Office of Management and Budget (OMB) approval.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before April 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Send your comments on the information collection request (ICR) by one of the following methods (please reference 1018-Snowy Plovers in the subject line of your comments):</P>
                    <P>
                        • 
                        <E T="03">Internet (preferred): https://www.regulations.gov</E>
                        . Follow the instructions for submitting comments on Docket No. FWS-R8-ES-2023-0107.
                    </P>
                    <P>
                        • 
                        <E T="03">Email: Info_Coll@fws.gov</E>
                        .
                    </P>
                    <P>
                        • 
                        <E T="03">U.S. mail:</E>
                         Service Information Collection Clearance Officer, U.S. Fish and Wildlife Service, 5275 Leesburg Pike, MS: PRB (JAO/3W), Falls Church, VA 22041-3803.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request additional information about this ICR, contact Madonna L. Baucum, Service Information Collection Clearance Officer, by email at 
                        <E T="03">Info_Coll@fws.gov,</E>
                         or by telephone at (703) 358-2503. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point-of-contact in the United States.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In accordance with the Paperwork Reduction Act (PRA, 44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) and its implementing regulations at 5 CFR 1320.8(d)(1), all information collections require approval under the PRA. We may not conduct or sponsor and you are not required to respond to a collection of information unless it displays a currently valid OMB control number.
                </P>
                <P>As part of our continuing effort to reduce paperwork and respondent burdens, we invite the public and other Federal agencies to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.</P>
                <P>We are especially interested in public comment addressing the following:</P>
                <P>(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;</P>
                <P>(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used;</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (4) How might the agency minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of response.
                </P>
                <P>Comments that you submit in response to this notice are a matter of public record. We will include or summarize each comment in our request to OMB to approve this ICR. Before including your address, phone number, email address, or other personal identifying information in your comment, you should be aware that your entire comment—including your personal identifying information—may be made publicly available at any time. While you can ask us in your comment to withhold your personal identifying information from public review, we cannot guarantee that we will be able to do so.</P>
                <P>
                    <E T="03">Abstract:</E>
                     The Endangered Species Act of 1973, as amended (ESA; 16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ), was established to provide a means to conserve the ecosystems upon which endangered and threatened species depend, to provide a program for the conservation of these endangered and threatened species, and to take the appropriate steps that are necessary to bring any endangered or threatened species to the point where measures provided for under the ESA are no longer necessary.
                </P>
                <P>
                    The western snowy plover (
                    <E T="03">Charadrius nivosus nivosus;</E>
                     hereafter referred to as plover) is a federally threatened species protected under the ESA. Corvid-caused predation is detrimental to plover survival and changes by site and by year. A corvid is any member of the Corvidae family of stout-billed passerine birds, such as crows, jays, magpies, and raven.
                </P>
                <P>The Western Snowy Plover Recovery Unit 2 Outreach Subcommittee is committed to plover outreach and education. The subcommittee is comprised of partners including the Arcata Fish and Wildlife Office, Humboldt Bay National Wildlife Refuge, California State Parks, National Park Service, Bureau of Land Management, Friends of the Dunes, Tolowa Dunes Stewards, Humboldt County Parks, and California State Polytechnic University-Humboldt. The Kure/Stuyvesant Trustee Council (KSTC) is composed of representatives from the Service, the California Department of Fish and Wildlife, and the California State Lands Commission and is the entity providing funding through the Kure/Stuyvesant Restoration Fund for Friends of the Dunes to complete the action described below.</P>
                <P>Crumb Clean Message Effectiveness Social Survey—The social survey for the redesigned Crumb Clean Campaign will be used to assess the effectiveness of the campaign's message (the campaign's goal is education on keeping wild animals from getting access to human food in California State Parks). Information collected will strictly be regarding the messaging of the Crumb Clean Campaign, and what can be done to improve the overall message quality and effectiveness. The survey will be administered three times during summer. Data collected will be used to inform any necessary adjustment to a required presentation on the Crumb Clean Campaign.</P>
                <P>Crumb Clean Report—A report on the results of the survey must be submitted to the Service. This report must be compliant with section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d).</P>
                <P>These reports will include Crumb Clean Questionnaire results, locations of distribution, and hours spent.</P>
                <P>• Related Information Collection Activities Already Approved by the Office of Management and Budget</P>
                <P>• Banding activities under the U.S. Geological Survey's “Bird Banding and Recovery Reports” (OMB Control No. 1028-0082);</P>
                <P>• ESA permitting activities under the Service's “Federal Fish and Wildlife Permit Applications and Reports—Native Endangered and Threatened Species; 50 CFR 10, 13, and 17” (OMB Control No. 1018-0094); and</P>
                <P>• Service Manual chapter 516 FW 1—Monitoring Financial and Performance Reporting for Financial Assistance (OMB Control No. 1018-0100).</P>
                <P>
                    The public may request a copy of the proposed survey instruments or any other document in this information collection by sending a request to the Service Information Collection Clearance Officer (see 
                    <E T="02">ADDRESSES</E>
                    ).
                </P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Western Snowy Plover Outreach and Monitoring.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1018-New.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     None.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     New collection in use without OMB approval.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     Individuals/households; private sector; and State, local, and Tribal governments.
                    <PRTPAGE P="8705"/>
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Required to obtain or retain a benefit for monitoring and annual reports, and voluntary for surveys.
                </P>
                <P>
                    <E T="03">Frequency of Collection:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Non hour Burden Cost:</E>
                     None.
                </P>
                <GPOTABLE COLS="06" OPTS="L2,tp0,i1" CDEF="s50,12,12,12,12,12">
                    <BOXHD>
                        <CHED H="1">Requirement</CHED>
                        <CHED H="1">
                            Average
                            <LI>number of</LI>
                            <LI>annual</LI>
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>number of</LI>
                            <LI>responses</LI>
                            <LI>each</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>number of</LI>
                            <LI>annual</LI>
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>completion</LI>
                            <LI>time per</LI>
                            <LI>response</LI>
                            <LI>(hours) *</LI>
                        </CHED>
                        <CHED H="1">
                            Estimated
                            <LI>annual</LI>
                            <LI>burden hours *</LI>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="05" RUL="s">
                        <ENT I="21">
                            <E T="02">Crumb Clean Message Effectiveness Social Survey (Individuals)</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00" RUL="s">
                        <ENT I="01">Individuals</ENT>
                        <ENT>50</ENT>
                        <ENT>1</ENT>
                        <ENT>50</ENT>
                        <ENT>0.25</ENT>
                        <ENT>13</ENT>
                    </ROW>
                    <ROW EXPSTB="05" RUL="s">
                        <ENT I="21">
                            <E T="02">Annual Report (Private Sector)</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Reporting</ENT>
                        <ENT>2</ENT>
                        <ENT>1</ENT>
                        <ENT>2</ENT>
                        <ENT>10</ENT>
                        <ENT>20</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Recordkeeping</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>1</ENT>
                        <ENT>2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Totals</ENT>
                        <ENT>50</ENT>
                        <ENT/>
                        <ENT>50</ENT>
                        <ENT/>
                        <ENT>13</ENT>
                    </ROW>
                    <TNOTE>* Rounded.</TNOTE>
                </GPOTABLE>
                <P>An agency may not conduct or sponsor and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The authority for this action is the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Madonna Baucum,</NAME>
                    <TITLE>Information Collection Clearance Officer, U.S. Fish and Wildlife Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02569 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4333-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Geological Survey</SUBAGY>
                <DEPDOC>[GX24GK009970000]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Landslide Hazards Risk Reduction Grants Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Geological Survey (USGS), Department of the Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995 (PRA), the USGS is proposing a new information collection.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         Find this particular information collection request (ICR) by selecting “Currently under Review—Open for Public Comments” or by using the search function. Please provide a copy of your comments by mail to USGS, Information Collections Clearance Officer, 12201 Sunrise Valley Drive, MS 159, Reston, VA 20192 or by email to 
                        <E T="03">gs-info_collections@usgs.gov.</E>
                         Please reference OMB Control Number 1028-NEW Landslide Hazards in the subject line of your comments.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request additional information about this ICR, contact Stephen Slaughter by email at 
                        <E T="03">sslaughter@usgs.gov,</E>
                         or by telephone at 720-483-3945. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point-of-contact in the United States. You may also view the ICR at 
                        <E T="03">http://www.reginfo.gov/public/do/PRAMain.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In accordance with the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) and 5 CFR 1320.8(d)(1), we provide the general public and other federal agencies with an opportunity to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.
                </P>
                <P>
                    A 
                    <E T="04">Federal Register</E>
                     notice with a 60-day public comment period soliciting comments on this collection of information was published on 09/11/2023, 88 FR 62389. No comments were received.
                </P>
                <P>As part of our continuing effort to reduce paperwork and respondent burdens, we are again soliciting comments from the public and other federal agencies on the proposed ICR that is described below. We are especially interested in public comment addressing the following:</P>
                <P>(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether or not the information will have practical utility;</P>
                <P>(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used;</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (4) How the agency might 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, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of response.
                </P>
                <P>Comments that you submit in response to this notice are a matter of public record. Before including your address, phone number, email address, or other personally identifiable information (PII) in your comment, you should be aware that your entire comment—including your PII—may be made publicly available at any time. While you can ask us in your comment to withhold your PII from public review, we cannot guarantee that we will be able to do so.</P>
                <P>
                    <E T="03">Abstract:</E>
                     USGS Cooperative Landslide Hazard Mapping and Assessment Program priorities reflect the National Landslide Preparedness Act (Pub. L. 116-323), which supports the mission of the USGS Landslide Hazards Program to reduce loss of lives and property from landslides and improve public safety and community 
                    <PRTPAGE P="8706"/>
                    resilience for the Nation. Proposed risk-reduction activities should advance landslide science and communication that underlie the priorities of the National Landslide Preparedness Act by focusing on landslide hazard planning, coordination, mapping, assessments, education, and outreach. The objectives are to provide grants on a competitive basis to state, territorial, local, and Tribal governments to research, map, assess, and collect data on landslide hazards within the jurisdictions of those governments. In response to our program announcements, applicants submit proposals in priority areas including (a) advancing landslide hazard mapping and assessments; (b) improving landslide hazard planning and coordination; and (c) improving the dissemination of landslide hazard information and its effectiveness in mitigating losses. This information is used as the basis for selection and award of projects meeting USGS Cooperative Landslide Hazard Mapping and Assessment Program priorities. Final grant close-out narrative reports are required for each funded proposal. Annual progress reports are required for awards that span more than two years. Final grant close-out narrative reports are made available to the public at 
                    <E T="03">https://www.usgs.gov/programs/landslide-hazards/science/external-grants-overview.</E>
                </P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Landslide Hazards Risk Reduction Grants Program.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1028-NEW.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     None.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     state, territorial, local, and tribal governments.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Respondents:</E>
                     The USGS estimates that 30 respondents will read the program announcement, 10 respondents will submit applications, and 10 respondents will submit semi-annual progress reports and a final technical report.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     10 applications; 10 semi-annual progress reports, and 10 final technical reports.
                </P>
                <P>
                    <E T="03">Estimated Completion Time per Response:</E>
                     Read program announcement: 1 hour; prepare applications: 40 hours; creating progress reports: 4 hours; producing the final technical report: 24 hours.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     710 hours.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Response is voluntary but required to be eligible to receive funding.
                </P>
                <P>
                    <E T="03">Frequency of Collection:</E>
                     Program announcements are published annually.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Non-hour Burden Cost:</E>
                     There are no non-hour cost burdens associated with this information collection.
                </P>
                <P>An agency may not conduct or sponsor, nor is a person is required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The authority for this action is the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Stephen L. Slaughter,</NAME>
                    <TITLE>Associate Program Coordinator for Landslide Hazards, Natural Hazards Mission Area, USGS.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02589 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4338-11-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Geological Survey</SUBAGY>
                <DEPDOC>[GX24MR00G6ZW800; OMB Control Number 1028-NEW]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Panhandle Terrapin Project</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Geological Survey, Department of the Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995 (PRA), the U.S. Geological Survey (USGS) is proposing a new information collection.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before April 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Send your comments on this information collection request (ICR) by mail to USGS, Information Collections Officer, 12201 Sunrise Valley Drive, MS 159, Reston, VA 20192 or by email to 
                        <E T="03">gs-info_collections@usgs.gov.</E>
                         Please reference OMB Control Number 1028-NEW Panhandle Terrapin Project in the subject line of your comments.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request additional information about this ICR, contact Margaret Lamont by email at 
                        <E T="03">mlamont@usgs.gov</E>
                         or by telephone at 352-209-4306. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point of contact in the United States. You may also view the ICR at 
                        <E T="03">http://www.reginfo.gov/public/do/PRAMain.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In accordance with the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) and 5 CFR 1320.8(d)(1), all information collections require approval. As part of our continuing effort to reduce paperwork and respondent burdens, we invite the public and other federal agencies to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.
                </P>
                <P>We are especially interested in public comment addressing the following:</P>
                <P>(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether or not the information will have practical utility;</P>
                <P>(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used;</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (4) How the agency might 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, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of response.
                </P>
                <P>Comments that you submit in response to this notice are a matter of public record. Before including your address, phone number, email address, or other personally identifiable information (PII) in your comment, you should be aware that your entire comment—including your PII—may be made publicly available at any time. While you can ask us in your comment to withhold your PII from public review, we cannot guarantee that we will be able to do so.</P>
                <P>
                    <E T="03">Abstract:</E>
                     The diamondback terrapin (
                    <E T="03">Malaclemys terrapin</E>
                    ) is a coastal turtle species that ranges along the U.S. coast from Massachusetts to Texas. As the only turtle species to live in brackish water (a mix of salt and fresh water), diamondback terrapins are typically found in habitats such as salt marshes, mangroves, estuaries, and bays. Their small size and cryptic coloring make locating terrapins difficult and, as such, terrapin populations often go undetected even within protected areas such as wildlife refuges and national parks. Because of this, there are large knowledge gaps about terrapin ecology. For example, the International Union for the Conservation of Nature did not 
                    <PRTPAGE P="8707"/>
                    consider Northwest Florida to be part of the diamondback terrapin's range, however new studies suggest that several relatively large populations inhabit this region. Since 2007, Florida Sea Grant has utilized citizen scientists to help locate terrapin nesting beaches in Northwest Florida. In 2017, the USGS partnered with Florida Sea Grant to expand these surveys. The new data-collection effort described here would support those surveys by providing an easily accessible, online data-collection method that would provide information on diamondback terrapin nesting activity and nesting habitat and potential anthropogenic threats at terrapin nesting sites. Citizens involved in the surveys receive training from Florida Sea Grant and the USGS prior to the start of the nesting season. Contributors are then assigned a survey route that is monitored weekly from April through October. When evidence of terrapin nesting activity is observed (
                    <E T="03">e.g.,</E>
                     a nesting terrapin, terrapin tracks, or eggshells), contributors would document the date, time, location, habitat, and environmental variables (including the presence of any invasive species), and the presence of predators and (or) potential anthropogenic threats (
                    <E T="03">e.g.,</E>
                     pets, garbage, or boats). Citizens also provide the date and time that their survey begins and ends, along with their initials and a way to contact them. Finally, monthly head count surveys are also conducted at each site which involves contributors sitting at the site for 30 minutes and documenting the number of terrapin heads that appear above the water's surface during that time period.
                </P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Panhandle Terrapin Project.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1028-NEW.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     None.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     New.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     Individuals.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Respondents:</E>
                     100.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     1,200.
                </P>
                <P>
                    <E T="03">Estimated Completion Time per Response:</E>
                     60 minutes.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     1,200 hours.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Voluntary.
                </P>
                <P>
                    <E T="03">Frequency of Collection:</E>
                     Weekly.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Nonhour Burden Cost:</E>
                     None.
                </P>
                <P>An agency may not conduct or sponsor, nor is a person required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The authority for this action is the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Margaret M. Lamont,</NAME>
                    <TITLE>Research Biologist, USGS Wetland and Aquatic Research Center.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02591 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4338-11-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Bureau of Indian Affairs</SUBAGY>
                <DEPDOC>[245A2100DD/AAKC001030/A0A501010.999900]</DEPDOC>
                <SUBJECT>Rate Adjustments for Indian Irrigation Projects</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of Indian Affairs, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Bureau of Indian Affairs (BIA) owns or has an interest in irrigation projects located on or associated with various Indian reservations throughout the United States. We are required to establish irrigation assessment rates to recover the costs to administer, operate, maintain, and rehabilitate these projects. We request your comments on the proposed rate adjustments.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested parties may submit comments on the proposed rate adjustments on or before April 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        All comments on the proposed rate adjustments must be in writing. You may send comments via email to 
                        <E T="03">comments@bia.gov.</E>
                         Please reference “Rate Adjustments for Indian Irrigation Projects” in the subject line. Or you may submit comments to the Program Specialist, Division of Water and Power, Office of Trust Services, 2021 4th Avenue North, Billings, Montana 59101.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Leslie Underwood, Program Specialist, Division of Water and Power, Office of Trust Services, (406) 657-5985. For details about a particular irrigation project, please use the table in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section to contact the BIA regional or local office where the project is located.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The first table in this notice provides contact information for individuals who can give further information about the irrigation projects covered by this notice. The second table provides the proposed rates for calendar year (CY) 2025 for all irrigation projects.</P>
                <HD SOURCE="HD1">What is the meaning of the key terms used in this notice?</HD>
                <P>In this notice:</P>
                <P>
                    <E T="03">Administrative costs</E>
                     mean all costs we incur to administer our irrigation projects at the local project level and are a cost factor included in calculating your operation and maintenance assessment. Costs incurred at the local project level do not normally include agency, region, or central office costs unless we state otherwise in writing.
                </P>
                <P>
                    <E T="03">Assessable acre</E>
                     means lands designated by us to be served by one of our irrigation projects, for which we collect assessments in order to recover costs for the provision of irrigation service. (
                    <E T="03">See also</E>
                     “total assessable acres.”)
                </P>
                <P>
                    <E T="03">BIA</E>
                     means the Bureau of Indian Affairs.
                </P>
                <P>
                    <E T="03">Bill</E>
                     means our statement to you of the assessment charges and/or fees you owe the United States for administration, operation, maintenance, and/or rehabilitation. The date we mail or hand-deliver your bill will be stated on it.
                </P>
                <P>
                    <E T="03">Costs</E>
                     means the costs we incur for administration, operation, maintenance, and rehabilitation to provide direct support or benefit to an irrigation facility. (
                    <E T="03">See</E>
                     administrative costs, operation costs, maintenance costs, and rehabilitation costs).
                </P>
                <P>
                    <E T="03">Customer</E>
                     means any person or entity to whom or to which we provide irrigation service.
                </P>
                <P>
                    <E T="03">Due date</E>
                     is the date on which your bill is due and payable. This date will be stated on your bill.
                </P>
                <P>
                    <E T="03">I, me, my, you</E>
                     and 
                    <E T="03">your</E>
                     mean all persons or entities that are affected by this notice.
                </P>
                <P>
                    <E T="03">Irrigation project</E>
                     means a facility or portion thereof for the delivery, diversion, and storage of irrigation water that we own or have an interest in, including all appurtenant works. The term “irrigation project” is used interchangeably with irrigation facility, irrigation system, and irrigation area.
                </P>
                <P>
                    <E T="03">Irrigation service</E>
                     means the full range of services we provide customers of our irrigation projects. This includes our activities to administer, operate, maintain, and rehabilitate our projects in order to deliver water.
                </P>
                <P>
                    <E T="03">Maintenance costs</E>
                     means costs we incur to maintain and repair our irrigation projects and associated equipment and is a cost factor included in calculating your operation and maintenance assessment.
                </P>
                <P>
                    <E T="03">Operation and maintenance (O&amp;M) assessment</E>
                     means the periodic charge you must pay us to reimburse costs of administering, operating, maintaining, and rehabilitating irrigation projects consistent with this notice and our supporting policies, manuals, and handbooks.
                    <PRTPAGE P="8708"/>
                </P>
                <P>
                    <E T="03">Operation or operating costs</E>
                     means costs we incur to operate our irrigation projects and equipment and is a cost factor included in calculating your O&amp;M assessment.
                </P>
                <P>
                    <E T="03">Past due bill</E>
                     means a bill that has not been paid by the close of business on the 30th day after the due date as stated on the bill. Beginning on the 31st day after the due date, we begin assessing additional charges accruing from the due date.
                </P>
                <P>
                    <E T="03">Rehabilitation costs</E>
                     means costs we incur to restore our irrigation projects or features to original operating condition or to the nearest state which can be achieved using current technology and is a cost factor included in calculating your O&amp;M assessment.
                </P>
                <P>
                    <E T="03">Responsible party</E>
                     means an individual or entity that owns or leases land within the assessable acreage of one of our irrigation projects and is responsible for providing accurate information to our billing office and paying a bill for an annual irrigation rate assessment.
                </P>
                <P>
                    <E T="03">Total assessable acres</E>
                     mean the total acres served by one of our irrigation projects.
                </P>
                <P>
                    <E T="03">Water delivery</E>
                     is an activity that is part of the irrigation service we provide our customers when water is available.
                </P>
                <P>
                    <E T="03">We, us,</E>
                     and 
                    <E T="03">our</E>
                     mean the United States Government, the Secretary of the Interior, the BIA, and all who are authorized to represent us in matters covered under this notice.
                </P>
                <HD SOURCE="HD1">Does this notice affect me?</HD>
                <P>This notice affects you if you own or lease land within the assessable acreage of one of our irrigation projects or if you have a carriage agreement with one of our irrigation projects.</P>
                <HD SOURCE="HD1">Where can I get information on the regulatory and legal citations in this notice?</HD>
                <P>
                    You can contact the appropriate office(s) for the irrigation project that serves you. Please use the table in the 
                    <E T="02">SUPPLEMENTARY INFORMATION</E>
                     section to contact the regional or local office where the project is located.
                </P>
                <HD SOURCE="HD1">Why are you publishing this notice?</HD>
                <P>We are publishing this notice to inform you that we propose to adjust our irrigation assessment rates. This notice is published in accordance with the BIA's regulations governing its operation and maintenance of irrigation projects, found at 25 CFR part 171. This regulation provides for the establishment and publication of the proposed rates for annual irrigation assessments as well as related information about our irrigation projects.</P>
                <HD SOURCE="HD1">What authorizes you to issue this notice?</HD>
                <P>Our authority to issue this notice is vested in the Secretary of the Interior by 5 U.S.C. 301 and the Act of August 14, 1914 (38 Stat. 583; 25 U.S.C. 385). The Secretary has in turn delegated this authority to the Assistant Secretary—Indian Affairs under part 209, Chapter 8.1A, of the Department of the Interior's Departmental Manual.</P>
                <HD SOURCE="HD1">When will you put the rate adjustments into effect?</HD>
                <P>We will put the rate adjustments into effect for CY 2024.</P>
                <HD SOURCE="HD1">How do you calculate irrigation rates?</HD>
                <P>We calculate annual irrigation assessment rates in accordance with 25 CFR 171.500 by estimating the annual costs of operation and maintenance at each of our irrigation projects and then dividing by the total assessable acres for that particular irrigation project. The result of this calculation for each project is stated in the rate table in this notice.</P>
                <HD SOURCE="HD1">What kinds of expenses do you consider in determining the estimated annual costs of operation and maintenance?</HD>
                <P>Consistent with 25 CFR 171.500, these expenses include the following:</P>
                <P>(a) Personnel salary and benefits for the project engineer/manager and project employees under the project engineer/manager's management or control;</P>
                <P>(b) Materials and supplies;</P>
                <P>(c) Vehicle and equipment repairs;</P>
                <P>(d) Equipment costs, including lease fees;</P>
                <P>(e) Depreciation;</P>
                <P>(f) Acquisition costs;</P>
                <P>(g) Maintenance of a reserve fund available for contingencies or emergency costs needed for the reliable operation of the irrigation facility infrastructure;</P>
                <P>(h) Maintenance of a vehicle and heavy equipment replacement fund;</P>
                <P>(i) Systematic rehabilitation and replacement of project facilities;</P>
                <P>(j) Contingencies for unknown costs and omitted budget items; and</P>
                <P>(k) Other expenses we determine necessary to properly perform the activities and functions characteristic of an irrigation project.</P>
                <HD SOURCE="HD1">When should I pay my irrigation assessment?</HD>
                <P>We will mail or hand deliver your bill notifying you (a) the amount you owe to the United States; and (b) when such amount is due. If we mail your bill, we will consider it as being delivered no later than five (5) business days after the day we mail it. You should pay your bill by the due date stated on the bill.</P>
                <HD SOURCE="HD1">What information must I provide for billing purposes?</HD>
                <P>All responsible parties are required to provide the following information to the billing office associated with the irrigation project where you own or lease land within the project's assessable acreage or to the billing office associated with the irrigation project with which you have a carriage agreement:</P>
                <P>(1) The full legal name of the person or entity responsible for paying the bill;</P>
                <P>(2) An adequate and correct address for mailing or hand delivering our bill; and</P>
                <P>(3) The taxpayer identification number or social security number of the person or entity responsible for paying the bill.</P>
                <HD SOURCE="HD1">Why are you collecting my taxpayer identification number or social security number?</HD>
                <P>Public Law 104-134, the Debt Collection Improvement Act of 1996, requires that we collect the taxpayer identification number or social security number before billing a responsible party and as a condition to servicing the account.</P>
                <HD SOURCE="HD1">What happens if I am a responsible party but I fail to furnish the information required to the billing office responsible for the irrigation project within which I own or lease assessable land or for which I have a carriage agreement?</HD>
                <P>If you are late paying your bill because of your failure to furnish the required information listed above, you will be assessed interest and penalties as provided below, and your failure to provide the required information will not provide grounds for you to appeal your bill or any penalties assessed.</P>
                <HD SOURCE="HD1">What can happen if I do not provide the information required for billing purposes?</HD>
                <P>We can refuse to provide you irrigation service.</P>
                <HD SOURCE="HD1">If I allow my bill to become past due, could this affect my water delivery?</HD>
                <P>
                    Yes. 25 CFR 171.545(a) states: “We will not provide you irrigation service until: (1) Your bill is paid; or (2) You make arrangement for payment pursuant to § 171.550 of this part.” If we do not receive your payment before the close of business on the 30th day after the due 
                    <PRTPAGE P="8709"/>
                    date stated on your bill, we will send you a past due notice. This past due notice will have additional information concerning your rights. We will consider your past due notice as delivered no later than five (5) business days after the day we mail it. We follow the procedures provided in 31 CFR 901.2, “Demand for Payment,” when demanding payment of your past due bill.
                </P>
                <HD SOURCE="HD1">Are there any additional charges if I am late paying my bill?</HD>
                <P>Yes. We are required to assess interest, penalties, and administrative costs on past due bills in accordance with 31 U.S.C. 3717 and 31 CFR 901.9. The rate of interest is established annually by the Secretary of the United States Treasury (Treasury) and accrues from the date your bill is past due. If your bill becomes more than 90 days past due, you will be assessed a penalty charge of no more than six percent per year, which accrues from the date your bill became past due. Each time we try to collect your past due bill, you will be charged an administrative fee of $12.50 for processing and handling.</P>
                <HD SOURCE="HD1">What else will happen to my past due bill?</HD>
                <P>If you do not pay your bill or make payment arrangements to which we agree, we are required to transfer your past due bill to Treasury for further action. Pursuant to 31 CFR 285.12, bills that are 120 days past due will be transferred to Treasury.</P>
                <HD SOURCE="HD1">Who can I contact for further information?</HD>
                <P>The contact table below contains the regional and project/agency contacts for our irrigation facilities.</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,p1,8/9,i1" CDEF="s50,r150">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Northwest Region Contacts</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">Bryan Mercier, Regional Director, Bureau of Indian Affairs, Northwest Regional Office, 911 NE 11th Avenue, Portland, OR 97232-4169. Telephone: (503) 231-6702.</ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Flathead Indian Irrigation Project</ENT>
                        <ENT>Eric Bruguier, Acting Irrigation Project Manager, 220 Project Drive, St. Ignatius, MT 59865. Telephone: (406) 745-2661.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Hall Irrigation Project</ENT>
                        <ENT>David Bollinger, Irrigation Project Manager, 36 Bannock Avenue, Fort Hall, ID 83203-0220. Telephone:(208) 238-1992.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Wapato Irrigation Project</ENT>
                        <ENT>Pete Plant, Project Administrator, 413 South Camas Avenue, Wapato, WA 98951-0220. Telephone: (509) 877-3155.</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Rocky Mountain Region Contacts</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">Susan Messerly, Regional Director, Bureau of Indian Affairs, Rocky Mountain Regional Office, 2021 4th Avenue North, Billings, MT 59101. Telephone: (406) 247-7943.</ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Blackfeet Irrigation Project</ENT>
                        <ENT>Kenneth Bird, Superintendent, Greg Tatsey, Irrigation Project Manager, P.O. Box 880, Browning, MT 59417. Telephones: Superintendent (406) 338-7544; Irrigation Project Manager (406) 338-7519.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crow Irrigation Project</ENT>
                        <ENT>Clifford Serawop, Superintendent, Jim Gappa, Acting Irrigation Project Manager (BIA), (Project O&amp;M performed by Water Users Association), P.O. Box 69, Crow Agency, MT 59022. Telephones: Superintendent (406) 638-2672; Acting Irrigation Project Manager (406) 247-7998.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Belknap Irrigation Project</ENT>
                        <ENT>Mark Azure, Superintendent, Jim Gappa, Acting Irrigation Project Manager (BIA), (Project O&amp;M contracted to Tribes under PL 93-638),158 Tribal Way, Suite B, Harlem, MT 59526. Telephones: Superintendent (406) 353-2901; Irrigation Project Manager, Tribal Office (406) 353-8454.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Peck Irrigation Project</ENT>
                        <ENT>Anna Eder, Superintendent, Jim Gappa, Acting Irrigation Project Manager (BIA), (Project O&amp;M performed by Fort Peck Water Users Association), P.O. Box 637, Poplar, MT 59255. Telephones: Superintendent (406) 768-5312; Acting Irrigation Project Manager (406) 247-7998</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Wind River Irrigation Project</ENT>
                        <ENT>Leslie Shakespeare, Superintendent, Jim Gappa, Acting Irrigation Project Manager (BIA), (Project O&amp;M for Little Wind, Johnstown, and Lefthand Units contracted to Tribes under PL 93-638; Little Wind-Ray and Upper Wind Units O&amp;M performed by Ray Canal, A Canal, and Crowheart Water Users Associations), P.O. Box 158, Fort Washakie, WY 82514. Telephones: Superintendent (307) 332-7810; Acting Irrigation Project Manager (406) 247-7998.</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Southwest Region Contacts</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Patricia L. Mattingly, Regional Director, Bureau of Indian Affairs, Southwest Regional Office, 1001 Indian School Road NW, Albuquerque, NM 87104. Telephone: (505) 563-3100.</ENT>
                    </ROW>
                    <ROW EXPSTB="00" RUL="s">
                        <ENT I="01">Pine River Irrigation Project</ENT>
                        <ENT>Priscilla Bancroft, Superintendent, Vickie Begay, Irrigation Project Manager, P.O. Box 315, Ignacio, CO 81137-0315. Telephones: Superintendent (970) 563-4511; Irrigation Project Manager (970) 563-9484.</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Western Region Contacts</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">Jessie Durham, Regional Director, Bureau of Indian Affairs, Western Regional Office, 2600 North Central Avenue, 4th Floor Mailroom, Phoenix, AZ 85004. Telephone: (602) 379-6600.</ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Colorado River Irrigation Project</ENT>
                        <ENT>Davetta Ameelyenah, Superintendent, Gary Colvin, Irrigation Project Manager, 12124 1st Avenue, Parker, AZ 85344. Telephones: Superintendent (928) 669-7111; (928) 662-4392 Irrigation Project Manager.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Duck Valley Irrigation Project</ENT>
                        <ENT>Phaline Conklin, Superintendent, (Project O&amp;M compacted to Shoshone-Paiute Tribes under PL 93-638), 2719 Argent Avenue, Suite 4, Gateway Plaza, Elko, NV 89801. Telephones: Superintendent (775) 738-5165; Tribal Office (208) 759-3100.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Yuma Project, Indian Unit</ENT>
                        <ENT>Maureen Brown, Superintendent, (Bureau of Reclamation (BOR) owns the Project and is responsible for O&amp;M), 256 South Second Avenue, Suite D, Yuma, AZ 85364. Telephones: Superintendent (928) 782-1202; BOR Area Office Manager (928) 343-8100.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="8710"/>
                        <ENT I="01">San Carlos Irrigation Project (Indian Works and Joint Works)</ENT>
                        <ENT>Ferris Begay, Project Manager (BIA), Clarence Begay, Supervisory Civil Engineer (BIA), (Portions of Indian Works O&amp;M compacted to Gila River Indian Community under PL 93-638; Joint Control Board is responsible for portions of Joint Works maintenance pursuant to Gila River Indian Community Water Rights Settlement Act of 2004, 118 Stat. 3499), 13805 North Arizona Boulevard, Coolidge, AZ 85128. Telephones: Project Manager (520) 723-6225; Supervisory Civil Engineer (520) 723-6203; Gila River Indian Irrigation &amp; Drainage District (520) 562-6720; Joint Control Board (520) 562-9760, (520) 723-5408.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Uintah Irrigation Project</ENT>
                        <ENT>Antonio Pingree, Superintendent, Ken Asay, Irrigation System Manager (BIA), (Project O&amp;M performed by Uintah Indian Irrigation Project Operation and Maintenance Company), P.O. Box 130, Fort Duchesne, UT 84026. Telephones: Superintendent (435) 722-4300; Irrigation System Manager (435) 722-4344; Uintah Indian Irrigation Operation and Maintenance Company (435) 724-5200.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Walker River Irrigation Project</ENT>
                        <ENT>Colleen Labelle, Superintendent, 311 East Washington Street, Carson City, NV 89701. Telephone: (775) 887-3500.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">What irrigation assessments or charges are proposed for adjustment by this notice?</HD>
                <P>The rate table below contains final CY 2024 rates for irrigation projects where we recover costs of administering, operating, maintaining, and rehabilitating them. The table also contains proposed CY 2025 rates for all irrigation projects. An asterisk immediately following the rate category notes irrigation projects where rates are proposed for adjustment.</P>
                <GPOTABLE COLS="4" OPTS="L2(,,0),nj,tp0,i1" CDEF="s100,r50,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Project name</CHED>
                        <CHED H="1">Rate category</CHED>
                        <CHED H="1">
                            Final
                            <LI>2024 rate</LI>
                        </CHED>
                        <CHED H="1">
                            Proposed
                            <LI>2025 rate</LI>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Northwest Region Rate Table</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Flathead Irrigation Project</ENT>
                        <ENT>Basic per acre—A</ENT>
                        <ENT>$39.00</ENT>
                        <ENT>$39.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre—B</ENT>
                        <ENT>19.50</ENT>
                        <ENT>19.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Minimum Charge per tract</ENT>
                        <ENT>75.00</ENT>
                        <ENT>75.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Hall Irrigation Project</ENT>
                        <ENT>Basic per acre *</ENT>
                        <ENT>65.50</ENT>
                        <ENT>66.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Minimum Charge per tract *</ENT>
                        <ENT>41.00</ENT>
                        <ENT>43.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Hall Irrigation Project—Minor Units</ENT>
                        <ENT>Basic per acre *</ENT>
                        <ENT>45.00</ENT>
                        <ENT>45.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Minimum Charge per tract *</ENT>
                        <ENT>41.00</ENT>
                        <ENT>43.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Hall Irrigation Project—Michaud Unit</ENT>
                        <ENT>Basic per acre *</ENT>
                        <ENT>75.00</ENT>
                        <ENT>75.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Pressure per acre *</ENT>
                        <ENT>116.50</ENT>
                        <ENT>117.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Minimum Charge per tract *</ENT>
                        <ENT>41.00</ENT>
                        <ENT>43.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wapato Irrigation Project—Toppenish/Simcoe Units</ENT>
                        <ENT>Minimum Charge per bill</ENT>
                        <ENT>28.00</ENT>
                        <ENT>28.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>28.00</ENT>
                        <ENT>28.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wapato Irrigation Project—Ahtanum Units</ENT>
                        <ENT>Minimum Charge per bill</ENT>
                        <ENT>35.00</ENT>
                        <ENT>35.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>35.00</ENT>
                        <ENT>35.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wapato Irrigation Project—Satus Unit</ENT>
                        <ENT>Minimum Charge per bill</ENT>
                        <ENT>100.00</ENT>
                        <ENT>100.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>“A” Basic per acre</ENT>
                        <ENT>86.00</ENT>
                        <ENT>86.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>“B” Basic per acre</ENT>
                        <ENT>92.00</ENT>
                        <ENT>92.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wapato Irrigation Project—Additional Works</ENT>
                        <ENT>Minimum Charge per bill</ENT>
                        <ENT>100.00</ENT>
                        <ENT>100.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>87.00</ENT>
                        <ENT>87.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wapato Irrigation Project—Water Rental</ENT>
                        <ENT>Minimum Charge per bill</ENT>
                        <ENT>100.00</ENT>
                        <ENT>100.00</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>100.00</ENT>
                        <ENT>100.00</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Rocky Mountain Region Rate Table</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Blackfeet Irrigation Project</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>21.50</ENT>
                        <ENT>21.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crow Irrigation Project—Willow Creek O&amp;M (includes Agency, Lodge Grass #1, Lodge Grass #2, Reno, Upper Little Horn, and Forty Mile Units)</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>30.00</ENT>
                        <ENT>30.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crow Irrigation Project—All Others (includes Bighorn, Soap Creek, and Pryor Units)</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>30.00</ENT>
                        <ENT>30.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crow Irrigation Project—Two Leggins Unit</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>15.00</ENT>
                        <ENT>15.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crow Irrigation Two Leggins Drainage District</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>3.00</ENT>
                        <ENT>3.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Belknap Irrigation Project</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>20.00</ENT>
                        <ENT>20.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fort Peck Irrigation Project</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>29.00</ENT>
                        <ENT>29.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wind River Irrigation Project—Units 2, 3 and 4</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>26.00</ENT>
                        <ENT>26.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wind River Irrigation Project—Unit 6</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>23.00</ENT>
                        <ENT>23.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wind River Irrigation Project—LeClair District (See Note #1)</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>47.00</ENT>
                        <ENT>47.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wind River Irrigation Project—Crow Heart Unit</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>16.50</ENT>
                        <ENT>16.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Wind River Irrigation Project—A Canal Unit</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>16.50</ENT>
                        <ENT>16.50</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Wind River Irrigation Project—Riverton Valley Irrigation District (See Note #1)</ENT>
                        <ENT>Basic-per acre</ENT>
                        <ENT>30.65</ENT>
                        <ENT>30.65</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <ENT I="21">
                            <E T="02">Southwest Region Rate Table</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Pine River Irrigation Project</ENT>
                        <ENT>Minimum Charge per tract</ENT>
                        <ENT>75.00</ENT>
                        <ENT>75.00</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22"> </ENT>
                        <ENT>Basic-per acre *</ENT>
                        <ENT>23.50</ENT>
                        <ENT>24.00</ENT>
                    </ROW>
                    <ROW EXPSTB="03" RUL="s">
                        <PRTPAGE P="8711"/>
                        <ENT I="21">
                            <E T="02">Western Region Rate Table</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Colorado River Irrigation Project</ENT>
                        <ENT>Basic per acre up to 5.75 acre-feet *</ENT>
                        <ENT>64.00</ENT>
                        <ENT>69.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Excess Water per acre-foot over 5.75 acre-feet</ENT>
                        <ENT>18.00</ENT>
                        <ENT>18.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Duck Valley Irrigation Project</ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>5.30</ENT>
                        <ENT>5.30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Yuma Project, Indian Unit (See Note #2)</ENT>
                        <ENT>Basic per acre up to 5.0 acre-feet *</ENT>
                        <ENT>184.00</ENT>
                        <ENT>( + )</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Excess Water per acre-foot over 5.0 acre-feet</ENT>
                        <ENT>35.00</ENT>
                        <ENT>( + )</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Basic per acre up to 5.0 acre-feet (Ranch 5)</ENT>
                        <ENT>184.00</ENT>
                        <ENT>( + )</ENT>
                    </ROW>
                </GPOTABLE>
                <GPOTABLE COLS="5" OPTS="L2(0,,),ns,tp0,p1,8/9,i1" CDEF="xs259,xs58,xs58,xs54,xs54">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW RUL="n,s">
                        <ENT I="01">San Carlos Irrigation Project (Joint Works) (See Note #3)</ENT>
                        <ENT A="01">Basic per acre</ENT>
                        <ENT>$26.00</ENT>
                        <ENT>$26.00</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="22"> </ENT>
                        <ENT A="03">Proposed 2025 Construction Water Rate Schedule:</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="25"> </ENT>
                        <ENT O="xl"/>
                        <ENT>
                            Off project
                            <LI>construction</LI>
                        </ENT>
                        <ENT>
                            On project
                            <LI>construction—</LI>
                            <LI>gravity water</LI>
                        </ENT>
                        <ENT>
                            On project
                            <LI>construction—</LI>
                            <LI>pump water</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Administrative Fee</ENT>
                        <ENT>$300.00</ENT>
                        <ENT>$300.00</ENT>
                        <ENT>$300.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Usage Fee</ENT>
                        <ENT>$250.00 per month</ENT>
                        <ENT>No Fee</ENT>
                        <ENT>$100.00 per acre foot.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Excess Water Rate †</ENT>
                        <ENT>$5.00 per 1,000 gal</ENT>
                        <ENT>No Charge</ENT>
                        <ENT>No Charge.</ENT>
                    </ROW>
                </GPOTABLE>
                <GPOTABLE COLS="4" OPTS="L2(0,,),ns,tp0,i1" CDEF="s100,r50,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Project name</CHED>
                        <CHED H="1">Rate category</CHED>
                        <CHED H="1">
                            Final
                            <LI>2024 rate</LI>
                        </CHED>
                        <CHED H="1">
                            Proposed
                            <LI>2025 rate</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">San Carlos Irrigation Project (Indian Works) (See Note #4)</ENT>
                        <ENT>Basic per acre</ENT>
                        <ENT>$99.62</ENT>
                        <ENT>$93.85</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Uintah Irrigation Project</ENT>
                        <ENT>Basic per acre *</ENT>
                        <ENT>23.00</ENT>
                        <ENT>25.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Minimum Bill</ENT>
                        <ENT>25.00</ENT>
                        <ENT>25.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Walker River Irrigation Project</ENT>
                        <ENT>Basic per acre *</ENT>
                        <ENT>31.00</ENT>
                        <ENT>32.00</ENT>
                    </ROW>
                    <TNOTE>* Notes irrigation projects where rates are adjusted.</TNOTE>
                    <TNOTE>+ These rates have not yet been determined.</TNOTE>
                    <TNOTE>† The excess water rate applies to all water used in excess of 50,000 gallons in any one month.</TNOTE>
                    <TNOTE>
                        <E T="02">Note #1:</E>
                         O&amp;M rates for LeClair and Riverton Valley Irrigation Districts apply to Trust lands that are serviced by each irrigation district. The annual O&amp;M rates are based on budgets submitted by LeClair and Riverton Valley Irrigation Districts, respectively.
                    </TNOTE>
                    <TNOTE>
                        <E T="02">Note #2:</E>
                         The O&amp;M rate for the Yuma Project, Indian Unit has two components. The first component of the O&amp;M rate is established by the Bureau of Reclamation (BOR), the owner and operator of the Project. BOR's rate, which is based upon the annual budget submitted by BOR is $180.00 for 2024 but has not been established for 2025. The second component of the O&amp;M rate is established by BIA to cover administrative costs, which includes billing and collections for the Project. The final 2024 BIA rate component is $4.00 per acre. The proposed 2025 BIA rate component is $4.50 per acre.
                    </TNOTE>
                    <TNOTE>
                        <E T="02">Note #3:</E>
                         The Construction Water Rate Schedule identifies fees assessed for use of irrigation water for non-irrigation purposes.
                    </TNOTE>
                    <TNOTE>
                        <E T="02">Note #4:</E>
                         The O&amp;M rate for the San Carlos Irrigation Project—Indian Works has three components. The first component is established by BIA San Carlos Irrigation Project—Indian Works, the owner and operator of the Project; the final 2024 rate is $55.85 per acre, and proposed 2025 rate is $55.85 per acre. The second component is established by BIA San Carlos Irrigation Project—Joint Works; the final 2024 rate is $26.00 per acre, and proposed 2025 rate is $26.00 per acre. The third component is established by the San Carlos Irrigation Project Joint Control Board (comprised of representatives from the Gila River Indian Community and the San Carlos Irrigation and Drainage District); the 2024 rate is $17.77 per acre, and 2025 rate is $12.00 per acre.
                    </TNOTE>
                </GPOTABLE>
                <HD SOURCE="HD1">Consultation and Coordination With Tribal Governments (Executive Order 13175)</HD>
                <P>The Department of the Interior strives to strengthen its government-to-government relationship with Indian Tribes through a commitment to consultation with Indian Tribes and recognition of their right to self-governance and Tribal sovereignty. We have evaluated this notice under the Department's consultation policy and under the criteria of Executive Order 13175 and have determined there to be substantial direct effects on federally recognized Tribes because the irrigation projects are located on or associated with Indian reservations. To fulfill its consultation responsibility to Tribes and Tribal organizations, BIA communicates, coordinates, and consults on a continuing basis with these entities on issues of water delivery, water availability, and costs of administration, operation, maintenance, and rehabilitation of projects that concern them. This is accomplished at the individual irrigation project by project, agency, and regional representatives, as appropriate, in accordance with local protocol and procedures. This notice is one component of our overall coordination and consultation process to provide notice to, and request comments from, these entities when we adjust irrigation assessment rates.</P>
                <HD SOURCE="HD1">Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use (Executive Order 13211)</HD>
                <P>The proposed rate adjustments are not a significant energy action under the definition in Executive Order 13211. A Statement of Energy Effects is not required.</P>
                <HD SOURCE="HD1">Regulatory Planning and Review (Executive Order 12866), as Amended by E.O. 14094)</HD>
                <P>
                    These proposed rate adjustments are not a significant regulatory action and do not need to be reviewed by the Office of Management and Budget under Executive Order 12866, as Amended by E.O. 14094.
                    <PRTPAGE P="8712"/>
                </P>
                <HD SOURCE="HD1">Regulatory Flexibility Act</HD>
                <P>These proposed rate adjustments are not a rule for the purposes of the Regulatory Flexibility Act because they establish “a rule of particular applicability relating to rates.” 5 U.S.C. 601(2).</P>
                <HD SOURCE="HD1">Unfunded Mandates Reform Act of 1995</HD>
                <P>
                    These proposed rate adjustments do not impose an unfunded mandate on state, local, or Tribal governments in the aggregate, or on the private sector, of more than $130 million per year. They do not have a significant or unique effect on State, local, or Tribal governments or the private sector. Therefore, the Department is not required to prepare a statement containing the information required by the Unfunded Mandates Reform Act (2 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <HD SOURCE="HD1">Takings (Executive Order 12630)</HD>
                <P>These proposed rate adjustments do not effect a taking of private property or otherwise have “takings” implications under Executive Order 12630. The proposed rate adjustments do not deprive the public, State, or local governments of rights or property.</P>
                <HD SOURCE="HD1">Federalism (Executive Order 13132)</HD>
                <P>Under the criteria in section 1 of Executive Order 13132, these proposed rate adjustments do not have sufficient federalism implications to warrant the preparation of a federalism summary impact statement because they will not affect the States, the relationship between the national government and the States, or the distribution of power and responsibilities among the various levels of government. A federalism summary impact statement is not required.</P>
                <HD SOURCE="HD1">Civil Justice Reform (Executive Order 12988)</HD>
                <P>This notice complies with the requirements of Executive Order 12988. Specifically, in issuing this notice, the Department has taken the necessary steps to eliminate drafting errors and ambiguity, minimize potential litigation, and provide a clear legal standard for affected conduct as required by section 3 of Executive Order 12988.</P>
                <HD SOURCE="HD1">Paperwork Reduction Act of 1995</HD>
                <P>These proposed rate adjustments do not affect the collections of information which have been approved by the Office of Information and Regulatory Affairs, Office of Management and Budget (OMB) under the Paperwork Reduction Act of 1995. The OMB Control Number is 1076-0141 and expires March 31, 2026.</P>
                <HD SOURCE="HD1">National Environmental Policy Act</HD>
                <P>The Department has determined that these proposed rate adjustments do not constitute a major Federal action significantly affecting the quality of the human environment and that no detailed statement is required under the National Environmental Policy Act of 1969, 42 U.S.C. 4321-4370(d), pursuant to 43 CFR 46.210(i). In addition, the proposed rate adjustments do not present any of the 12 extraordinary circumstances listed at 43 CFR 46.215.</P>
                <SIG>
                    <NAME>Bryan Newland,</NAME>
                    <TITLE>Assistant Secretary—Indian Affairs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02596 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4337-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037345; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Ohio History Connection, Columbus, OH</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Ohio History Connection has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Fulton, Henry, and Williams Counties, Ohio.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nekole Alligood, NAGPRA Specialist, Ohio History Connection, 800 E 17th Avenue, Columbus, OH 43211, telephone (614) 297-2300, email 
                        <E T="03">nalligood@ohiohistory.org</E>
                        .
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Ohio History Connection. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Ohio History Connection.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>The following were recovered from three counties in northwest Ohio, Fulton, Henry, and Williams Counties.</P>
                <P>33 FU 5, Patyi-Dowling Site, Fulton Township, Fulton County, Ohio. There are two individuals who were exhumed by Robert Cufr and reported by David Stothers with the University of Toledo in 1972. The remains were retained by the Firelands Archaeological Research Center and donated by them to the Ohio History Connection in 2021. There are three associated funerary objects included; one coral or shell piece with yellowish staining and two small animal long bone fragments.</P>
                <P>33 FU 101, Fish Site, Royalton Township, Fulton County, Ohio. One adult human tooth was found at this site. The 70 associated funerary objects consist of several components ranging from the Early Archaic to the Late Woodland period. Specific provenience of the objects is unknown, they were surface finds collected at the same location.</P>
                <P>Pioneer, Madison Township, Williams County, Ohio. This one individual was received from the Lucas County Coroner's Office in 2020 and was brought to Ohio History Connection in 2021.</P>
                <P>33 HY 127, Brown Site No. 1, Damascus Township, Henry County, Ohio. There are two individuals who were likely exhumed in the early 1980s from a site along the Maumee River bank and were donated to the Firelands Archaeological Research Center who then donated them to the Ohio History Connection in 2021. There are eight lots of various affiliated objects consisting of ceramic sherds, faunal remains, shell fragments, debitage and soil.</P>
                <P>Ritter Park, Napoleon Township, Henry County, Ohio. The two individuals were exhumed from the Maumee River bank. The Lucas County Coroner's Office transferred them to Ohio History Connection in 2019.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>
                    The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological 
                    <PRTPAGE P="8713"/>
                    information, geographical information, and indigenous knowledge from the consulting Indian Tribes.
                </P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Ohio History Connection has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of eight individuals of Native American ancestry.</P>
                <P>• The 81 objects described in this notice are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Absentee-Shawnee Tribe of Indians of Oklahoma; Bad River Band of the Lake Superior Tribe of Chippewa Indians of the Bad River Reservation, Wisconsin; Bay Mills Indian Community, Michigan; Cayuga Nation; Chippewa Cree Indians of the Rocky Boy's Reservation, Montana; Citizen Potawatomi Nation, Oklahoma; Delaware Nation, Oklahoma; Delaware Tribe of Indians; Eastern Shawnee Tribe of Oklahoma; Forest County Potawatomi Community, Wisconsin; Grand Traverse Band of Ottawa and Chippewa Indians, Michigan; Hannahville Indian Community, Michigan; Kaw Nation, Oklahoma; Keweenaw Bay Indian Community, Michigan; Lac Courte Oreilles Band of Lake Superior Chippewa Indians of Wisconsin; Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin; Lac Vieux Desert Band of Lake Superior Chippewa Indians of Michigan; Little River Band of Ottawa Indians, Michigan; Little Shell Tribe of Chippewa Indians of Montana; Little Traverse Bay Bands of Odawa Indians, Michigan; Match-e-be-nash-she-wish Band of Pottawatomi Indians of Michigan; Miami Tribe of Oklahoma; Minnesota Chippewa Tribe, Minnesota (Six component reservations: Bois Forte Band (Nett Lake); Fond du Lac Band; Grand Portage Band; Leech Lake Band; Mille Lacs Band; White Earth Band); Nottawaseppi Huron Band of the Potawatomi, Michigan; Omaha Tribe of Nebraska; Oneida Indian Nation; Oneida Nation; Onondaga Nation; Ottawa Tribe of Oklahoma; Pokagon Band of Potawatomi Indians, Michigan and Indiana; Ponca Tribe of Indians of Oklahoma; Ponca Tribe of Nebraska; Prairie Band Potawatomi Nation; Red Cliff Band of Lake Superior Chippewa Indians of Wisconsin; Red Lake Band of Chippewa Indians, Minnesota; Saginaw Chippewa Indian Tribe of Michigan; Saint Regis Mohawk Tribe; Sault Ste. Marie Tribe of Chippewa Indians, Michigan; Seneca Nation of Indians; Seneca-Cayuga Nation; Shawnee Tribe; Sokaogon Chippewa Community, Wisconsin; St. Croix Chippewa Indians of Wisconsin; Tonawanda Band of Seneca; Turtle Mountain Band of Chippewa Indians of North Dakota; Tuscarora Nation; and the Wyandotte Nation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Ohio History Connection must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Ohio History Connection is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02552 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-CR-NPS0037072; PPWOCRADP3, PCU00RP15.R50000 234P104215 (223); OMB Control Number 1024-0038]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Submission to the Office of Management and Budget for Review and Approval; Procedures for State, Tribal, and Local Government Historic Preservation Programs and Management of Historic Preservation Fund Grants</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, we, the National Park Service (NPS) are proposing to revise an information collection with revisions.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and suggestions on the information collection requirements should be submitted by the date specified above in DATES to 
                        <E T="03">http://www.reginfo.gov/public/do/PRAMain.</E>
                         Find this particular information collection by selecting “Currently under Review—Open for Public Comments” or by using the search function. Please provide a copy of your comments to the NPS Information Collection Clearance Officer (ADIR-ICCO), 13461 Sunrise Valley Drive, (MS 244) Herndon, VA 20171 (mail); or 
                        <E T="03">phadrea_ponds@nps.gov</E>
                         (email). Please reference OMB Control Number 1024-0038 in the subject line of your comments.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request additional information about this ICR, contact Seth Tinkham, Grants Management Specialist, State, Tribal, Local, Plans &amp; Grants Division at 
                        <E T="03">seth_tinkham@nps.gov</E>
                         (email); or 202 354-2045 (telephone). Please reference OMB Control Number 1024-0038 in the subject line of your comments. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States 
                        <PRTPAGE P="8714"/>
                        should use the relay services offered within their country to make international calls to the point of contact in the United States. You may also view the ICR at 
                        <E T="03">http://www.reginfo.gov/public/do/PRAMain.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In accordance with the Paperwork Reduction Act of 1995 (PRA, 44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) and 5 CFR 1320.8(d)(1), we provide the general public and other Federal agencies with an opportunity to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.
                </P>
                <P>
                    A 
                    <E T="04">Federal Register</E>
                     notice with a 60-day public comment period soliciting comments on this collection of information was published on June 6, 2023 (88 FR 37093). No comments were received.
                </P>
                <P>As part of our continuing effort to reduce paperwork and respondent burdens, we are again soliciting comments from the public and other Federal agencies on the proposed ICR that is described below. We are especially interested in public comment addressing the following:</P>
                <P>(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether or not the information will have practical utility.</P>
                <P>(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used.</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected.</P>
                <P>
                    (4) How might the agency minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of response.
                </P>
                <P>Comments that you submit in response to this notice are a matter of public record. 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.</P>
                <P>
                    <E T="03">Abstract:</E>
                     This collection is authorized by Section 101(b) of the National Historic Preservation Act, as amended (54 U.S.C. 302301), which specifies the role of States, Tribes, and local governments in the Historic Preservation Program (HPP). This information collection has an impact on State, Tribal, and local governments that wish to participate formally with the National Park Service in the HPP. Information is also requested to meet grant management and monitoring responsibilities for States, Tribes, local government, and other eligible grant recipients under 54 U.S.C. 300101 
                    <E T="03">et seq.</E>
                     and 2 CFR 200.
                </P>
                <P>Each year Congress directs the NPS to use part of the annual appropriation from the Historic Preservation Fund (HPF) for the State grant program and the Tribal grant programs to assist States and Tribes in carrying out their statutory role in the HPP. Through competitive grant programs, Congress also directs NPS to provide financial assistance to a variety of eligible grant recipients to support the broad cultural resource mandates of the National Historic Preservation Act and for other purposes.</P>
                <P>
                    We use these information collections to manage our statutory partnerships and for managing grants (usually to those same partners). We are requesting to update the name of this collection from “
                    <E T="03">Procedures for State, Tribal, and Local Government Historic Preservation Programs”</E>
                     to “
                    <E T="03">Procedures for State, Tribal, and Local Government Historic Preservation Programs &amp; Management of Historic Preservation Fund Grants.”</E>
                     This change is to clarify our roles in managing our statutory partnerships and competitive (project) grants and formula grants.
                </P>
                <P>The information from this collection is required to determine if State, Tribal, and local governments meet minimum standards and requirements for participation in the HPP and to meet program-specific requirements as well as government-wide requirements for Federal grant programs. We propose to discontinue the HPF Online Closeout/EOY (State Sources of Non-federal Matching Share Report). The extra reporting effort is redundant and is not useful in evaluating grantee performance or compliance.</P>
                <P>The NPS uses the information collected to ensure compliance with the National Historic Preservation Act, as well as government-wide grant requirements issued and implemented through 43 CFR 12 and 2 CFR 200.</P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Procedures for State, Tribal, and Local Government Historic Preservation Programs &amp; Management of Historic Preservation Fund Grants.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1024-0038.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     NPS Forms 10-2060 through 10-2065.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Revision of a currently approved collection.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     State, Tribal, local governments, and grant applicants or recipients who wish to participate formally in the National Historic Preservation Program and/or who wish to apply for Historic Preservation Fund grant assistance.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     43,056.
                </P>
                <P>
                    <E T="03">Estimated Completion Time per Response:</E>
                     Varies from 10 minutes to hours to 40 hours depending on activity.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     40,644.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Required to obtain or retain a benefit.
                </P>
                <P>
                    <E T="03">Frequency of Collection:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Nonhour Burden Cost:</E>
                     None.
                </P>
                <P>An agency may not conduct or sponsor and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The authority for this action is the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Phadrea Ponds,</NAME>
                    <TITLE>Information Collection Clearance Officer, National Park Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02584 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037346; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Ohio History Connection, Columbus, OH</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Ohio History Connection has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects 
                        <PRTPAGE P="8715"/>
                        were removed from Hancock County, Ohio.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nekole Alligood, NAGPRA Specialist, Ohio History Connection, 800 E 17th Avenue, Columbus, OH 43211, telephone (614) 297-2300, email 
                        <E T="03">nalligood@ohiohistory.org.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Ohio History Connection. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Ohio History Connection.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>The following were recovered from Hancock County, Ohio.</P>
                <P>33 HK 5, Richard F. Moyer Kame Site, Mount Corey, Union Township, Hancock County, Ohio. Eight individuals were exhumed during a salvage excavation by Ohio Historical Society (now the Ohio History Connection) staff and by Mrs. Moyer. The excavations were conducted by Jack Shaffer, Raymond Baby, and Beverly Rettig in July-August 1957. Richard Moyer donated the individuals along with two faunal remain fragments and one animal tooth (possibly fish).</P>
                <P>33 HK 53, Shick Cemetery, Mount Corey, Union Township, Hancock County, Ohio. The remains of 10 individuals were exhumed during a basement enlargement project. The individuals were donated to the Ohio History Connection by Mark C. Schick in 2000. There are four juveniles and six adults.</P>
                <P>33 HK 6, Washington Township, Hancock County, Ohio. There are five individuals found on the surface from a destroyed multicomponent campsite (Solether Site) that were collected by Rick Siferd and Jeff Krazynski, who then gifted the individuals to the Ohio History Connection. No dates were included. There was one associated funerary object, a deer, or elk scapula, also found.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological information, geographical information, and indigenous knowledge from the consulting Tribes.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Ohio History Connection has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of 23 individuals of Native American ancestry.</P>
                <P>• There are four objects described in this notice are believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Absentee-Shawnee Tribe of Indians of Oklahoma; Cayuga Nation; Delaware Nation, Oklahoma; Delaware Tribe of Indians; Eastern Shawnee Tribe of Oklahoma; Kaw Nation, Oklahoma; Little River Band of Ottawa Indians, Michigan; Little Traverse Bay Bands of Odawa Indians, Michigan; Miami Tribe of Oklahoma; Omaha Tribe of Nebraska; Oneida Indian Nation; Oneida Nation; Onondaga Nation; Ottawa Tribe of Oklahoma; Ponca Tribe of Indians of Oklahoma; Ponca Tribe of Nebraska; Sac &amp; Fox Nation of Missouri in Kansas and Nebraska; Sac &amp; Fox Nation, Oklahoma; Sac &amp; Fox Tribe of the Mississippi in Iowa; Saint Regis Mohawk Tribe; Seneca-Cayuga Nation; Shawnee Tribe; Tonawanda Band of Seneca; Tuscarora Nation; and the Wyandotte Nation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Ohio History Connection must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Ohio History Connection is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02553 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037352; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve, Glen Cove, NY</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Suffolk County, NY.</P>
                </SUM>
                <DATES>
                    <PRTPAGE P="8716"/>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Veronica Natale, Museum Director—Garvies Point Museum and Preserve, 50 Barry Drive, Glen Cove, NY 11542, telephone (516) 571-8010, email 
                        <E T="03">vnatale@nassaucountyny.gov</E>
                         and Darcy Belyea, Commissioner of Parks, Nassau County Department of Parks, Recreation and Museums, email 
                        <E T="03">dbelyea@nassaucountyny.gov.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Nassau County Department of Parks, Recreation and Museums. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>In 1966, Nassau County Museum (NCM) Archaeologists recovered the partial human remains of, at minimum, two male adults found in a single grave during development of an area for housing. They were removed from NCM Site #1, Catalog number 1-1, Stony Hollow-Water's Edge, Centerport, Suffolk County, NY. Six associated funerary objects; Levanna points were found in association with grave; four have been located. Archeological evidence dates the human remains to the Late Woodland period.</P>
                <P>Sometime between 1966-1969, a fragmentary human skull, representing at minimum, one individual was found by others at an unknown location and removed from Strong's Neck, Suffolk County, NY. In 1969, the cranial fragments were donated to the museum by Ken Robinson, an archeologist involved at this site, Catalog number 63-x-113. No associated funerary objects are present. Time period is unknown.</P>
                <P>Human remains representing, at minimum, 24 individuals were removed from Suffolk County, NY. (Catalog number 132-x-1) Provenance: NCM #32, Soak Hides, Three Mile Harbor, NY. No associated funerary objects are present. Archeological evidence dates the site and human remains to the Woodland period.</P>
                <P>Human remains representing, at minimum, one individual were removed from Suffolk County, NY. (Catalog number 136-79) Excavated by Suffolk County Police, March 1971. Medical Examiner #0706. Site was located on private property of Mr. Paul Windels Jr. and he subsequently donated the human remains to the museum in 1972. Provenance: NCM #136, Stony Brook Harbor site, Nissequogue, NY. 11 associated funerary objects were found which include eight quartz projectile point fragments, a bead, deer scapula fragment, and fire-cracked hammerstone. Site has late Archaic through Late Woodland time.</P>
                <P>Human remains representing, at minimum, one individual were removed from Suffolk County, NY. (Catalog number 151-x) The frontal bone of a skull and two small skull fragments. Recovered by a bayman with clam tongs. Provenance: NCM Site #151, Plax site, Westhampton Beach, NY. No associated funerary objects are present.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological, geographical, historical, kinship, oral tradition, and expert opinion.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of 29 individuals of Native American ancestry.</P>
                <P>• The 15 objects described in this notice are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Shinnecock Indian Nation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Nassau County Department of Parks, Recreation and Museums—Garvies Point Museum and Preserve is responsible for sending a copy of this notice to the Indian Tribe identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02559 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037348; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Ohio History Connection, Columbus, OH</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <PRTPAGE P="8717"/>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Ohio History Connection has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Lucas County, Ohio.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nekole Alligood, NAGPRA Specialist, Ohio History Connection, 800 E. 17th Avenue, Columbus, OH 43211, telephone (614) 297-2300, email 
                        <E T="03">nalligood@ohiohistory.org</E>
                        .
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Ohio History Connection. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Ohio History Connection.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>Human remains representing at minimum 72 individuals were removed from different sites in Lucas County, Ohio.</P>
                <P>33 LU 394, Missionary Island 4 Site, Lucas County, Ohio. There are 29 individuals who were exhumed in 1983 and donated to the Firelands Archaeological Research Center in 1991. The individuals were then donated to the Ohio History Connection in 2021. There are 73 associated funerary objects with these people ranging from a ceramic vessel, pottery sherds, faunal remains, charcoal, and debitage.</P>
                <P>33 LU 118, Petrie Site, Toledo, Lucas County, Ohio. There are nine individuals, two adults, one adolescent and six juveniles. Faunal remains were found associated with these individuals.</P>
                <P>33 LU 28, Spiegle Site, Toledo, Lucas County, Ohio. There is one individual who was exhumed in the 1970's from the floodplain of the Maumee River in Toledo. They were then donated to the Firelands Archaeological Research Center, who then donated them to the Ohio History Connection in 2021.</P>
                <P>33 LU 6, Waterworks Mound Site, Jerusalem Township, Lucas County, Ohio. There are 28 individuals who were removed from a burial mound in the 1970s and donated to the Firelands Archaeological Research Center, who then donated them to Ohio History Connection in 2021. This is an ossuary burial, and while we have come to an MNI of 28, the remains are cremated and comingled. There were two associated funerary objects found among the remains, one cylindrical bead fragment made of bird bone, and faunal remains.</P>
                <P>33 LU 95, Morrison Site, Waterville Township, Lucas County, Ohio. One individual was likely exhumed in the 1970s or 1980s and donated to Firelands Archaeological Research Center, who then donated them to Ohio History Connection in 2021. Faunal remains were found with the individual.</P>
                <P>33 LU 43, Deer Site, Waterville Township, Lucas County, Ohio. Four individuals, including three juveniles and one adult. On an unknown date, they were exhumed and donated to Firelands Archaeological Research Center. The individuals were then donated to Ohio History Connection in 2021. One unmodified stone and faunal remains were found with these individuals.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological information, geographical information, and indigenous knowledge from the consulting Indian Tribes.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Ohio History Connection has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of 72 individuals of Native American ancestry.</P>
                <P>• The 79 objects described in this notice are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>
                    • There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Absentee-Shawnee Tribe of Indians of Oklahoma; Bad River Band of the Lake Superior Tribe of Chippewa Indians of the Bad River Reservation, Wisconsin; Bay Mills Indian Community, Michigan; Cayuga Nation; Chippewa Cree Indians of the Rocky Boy's Reservation, Montana; Citizen Potawatomi Nation, Oklahoma; Delaware Nation, Oklahoma; Delaware Tribe of Indians; Eastern Shawnee Tribe of Oklahoma; Forest County Potawatomi Community, Wisconsin; Grand Traverse Band of Ottawa and Chippewa Indians, Michigan; Hannahville Indian Community, Michigan; Kaw Nation, Oklahoma; Keweenaw Bay Indian Community, Michigan; Kickapoo Traditional Tribe of Texas; Kickapoo Tribe of Indians of the Kickapoo Reservation in Kansas; Kickapoo Tribe of Oklahoma; Lac Courte Oreilles Band of Lake Superior Chippewa Indians of Wisconsin; Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin; Lac Vieux Desert Band of Lake Superior Chippewa Indians of Michigan; Little River Band of Ottawa Indians, Michigan; Little Shell Tribe of Chippewa Indians of Montana; Little Traverse Bay Bands of Odawa Indians, Michigan; Match-e-be-nash-she-wish Band of Pottawatomi Indians of Michigan; Miami Tribe of Oklahoma; Minnesota Chippewa Tribe, Minnesota (Six component reservations: Bois Forte Band (Nett Lake); Fond du Lac Band; Grand Portage Band; Leech Lake Band; Mille Lacs Band; White Earth Band); Nottawaseppi Huron Band of the Potawatomi, Michigan; Omaha Tribe of Nebraska; Oneida Indian Nation; Oneida Nation; Onondaga Nation; Ottawa Tribe of Oklahoma; Peoria Tribe of Indians of Oklahoma; Pokagon Band of Potawatomi Indians, Michigan and Indiana; Ponca Tribe of Indians of Oklahoma; Ponca Tribe of Nebraska; Prairie Band Potawatomi Nation; Red Cliff Band of Lake Superior Chippewa Indians of Wisconsin; Red Lake Band of Chippewa Indians, Minnesota; Sac &amp; Fox Nation of Missouri in Kansas and Nebraska; Sac &amp; Fox Nation, Oklahoma; Sac &amp; Fox Tribe of the Mississippi in Iowa; Saginaw Chippewa Indian Tribe of Michigan; Saint Regis Mohawk Tribe; Sault Ste. Marie Tribe of Chippewa Indians, Michigan; Seneca Nation of Indians; Seneca-Cayuga Nation; Shawnee Tribe; Sokaogon Chippewa Community, Wisconsin; St. Croix Chippewa Indians of Wisconsin; Tonawanda Band of Seneca; Turtle Mountain Band of Chippewa Indians of 
                    <PRTPAGE P="8718"/>
                    North Dakota; Tuscarora Nation; and the Wyandotte Nation.
                </P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Ohio History Connection must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Ohio History Connection is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02555 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037341; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Intent To Repatriate Cultural Items: Central Washington University, Ellensburg, WA</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), Central Washington University intends to repatriate certain cultural items that meet the definition of unassociated funerary objects and that have a cultural affiliation with the Indian Tribes or Native Hawaiian organizations in this notice. The cultural items were removed from Grant, Kittitas, and Yakima County, WA.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the cultural items in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Lourdes Henebry-DeLeon, Department of Anthropology and Museum Studies, Central Washington University, 400 University Way, Ellensburg, WA 98926-7544, telephone (509) 963-2671, email 
                        <E T="03">Lourdes.Henebry-DeLeon@cwu.edu.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of Central Washington University. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the summary or related records held by Central Washington University.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>Between 1913 and 1943, 51 lots of unassociated funerary objects were removed from burial sites along the Columbia River in Grant, Kittitas, and Yakima Counties in Washington. They were excavated by Dr. Linus Walker, a private collector from Ellensburg, Kittitas County, WA, who donated most of his collection to Central Washington University in 1953. The 51 lots of unassociated funerary objects are 1 lot of adzes, 1 lot of anchor stones, 1 lot of war clubs, 1 lot of knives, 1 lot mortars, 3 lots of paint cups, 2 lots of ochre, 7 lots of pestles, 2 lots of pipes, 16 lots of modified shell, 10 lots of trade beads, 1 lot of manos, 1 lot of net sinkers, 1 lot of whetstones, 1 lot of hammers, 1 lot of faunal material, and 1 lot modified sandstone.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The cultural items in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archaeological, geographical, historical, and expert opinion.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, Central Washington University has determined that:</P>
                <P>• The 51 lots of cultural items described above are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony and are believed, by a preponderance of the evidence, to have been removed from a specific burial site of a Native American individual.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the cultural items and the Confederated Tribes and Band of the Yakama Nation and the Confederated Tribes of the Colville Reservation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Additional, written requests for repatriation of the cultural items in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization and, if joined to a request from one or more of the Indian Tribes, the Wanapum Band of Priest Rapids, a non-federally recognized Indian group.
                </P>
                <P>Repatriation of the cultural items in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Central Washington University must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the cultural items are considered a single request and not competing requests. Central Washington University is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                    <PRTPAGE P="8719"/>
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3004, and the implementing regulations, 43 CFR 10.9.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02549 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037342; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Central Washington University, Ellensburg, WA</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), Central Washington University has completed an inventory of human remains and associated funerary objects has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Grant and Kittitas Counties, WA.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Lourdes Henebry-DeLeon, Department of Anthropology and Museum Studies, Central Washington University, 400 University Way, Ellensburg, WA 98926-7544, telephone (509) 963-2671, email 
                        <E T="03">Lourdes.Henebry-DeLeon@cwu.edu.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of Central Washington University. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by Central Washington University.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>Between 1925 and 1990, human remains representing at minimum, 65 individuals were removed from Kittitas and Grant Counties, WA. Five lots of associated funerary objects are present.</P>
                <P>Between 1925 and 1935, human remains representing, at minimum, 32 individuals were removed from Whiskey Dick Bar, site 45-KT-17, in Kittitas County, WA, by Dr. Linus Walker. In 1953, Dr. Walker donated the remains to Central Washington University. No associated funerary objects are present.</P>
                <P>Between 1935 and 1937, CWU Professor George Beck removed human remains representing at minimum, four individuals during a fossil collecting expedition in Kittitas County, WA. One individual was in a grave at Whiskey Dick Bar, (45-KT-17), two individuals were removed from the area near the town of Vantage, and one individual from Montgomery Bar, site 45-KT-8. No associated funerary objects are present.</P>
                <P>Between 1953-1954, human remains representing, at minimum, two individuals were removed from the Cedar Cave, site 45-KT-20 in Kittitas County, WA, as part of a University of Washington field expedition by Dr. Earl Swanson. Subsequently, the Burke Museum donated these human remains to Central Washington University. No associated funerary objects are present.</P>
                <P>In the 1970's and 1980's human remains representing, at minimum, 11 individuals were removed from the area near the town of Vantage in Kittitas County, WA, by unknown individuals and donated to Central Washington University. No associated funerary objects are present.</P>
                <P>In the early 1900s, human remains representing, at minimum, 13 individuals were removed from “Middle Columbia River”, in Kittitas County, WA, by private collectors. Subsequently, these human remains were donated to Central Washington University by unknown individuals. No associated funerary objects are present.</P>
                <P>In 1970, human remains representing, at minimum, two individuals were removed from the Grissom Site (45-KT-301) in Kittitas County, WA, by a Central Washington University archaeology field school. The five associated funerary objects are one lot of matting, one lot of historic beads, one lot of metal buttons, one lot of seeds, and one lot flakes.</P>
                <P>Human remains representing, at minimum, one individual were removed from Crab Creek near the town of Beverly, in Grant County, WA and subsequently donated to Central Washington University by unknown individuals. No associated funerary objects are present.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological, biological, geographical, and historical.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, Central Washington University has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of 65 individuals of Native American ancestry.</P>
                <P>• The five lots of objects described in this notice are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Confederated Tribes and Bands of the Yakama Nation and the Confederated Tribes of the Colville Reservation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice and, if joined to a request from one or more of the Indian Tribes, the Wanapum Band of Priest Rapids, a non-federally recognized Indian group.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>
                    Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, Central Washington University must 
                    <PRTPAGE P="8720"/>
                    determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. Central Washington University is responsible for sending a copy of this notice to the Indian Tribes identified in this notice.
                </P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02550 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037350; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Peabody Museum of Archaeology and Ethnology, Harvard University, Cambridge, MA</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Peabody Museum of Archaeology and Ethnology, Harvard University (PMAE) has completed an inventory of human remains and has determined that there is a cultural affiliation between the human remains and Indian Tribes or Native Hawaiian organizations in this notice. The human remains were collected at the Sherman Institute, Riverside County, CA, and the Carson Indian School, Carson City County, NV.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Jane Pickering, Peabody Museum of Archaeology and Ethnology, Harvard University, 11 Divinity Avenue, Cambridge, MA 02138, telephone (617) 496-2374, email 
                        <E T="03">jpickering@fas.harvard.edu.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the PMAE. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the PMAE.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>Human remains representing, at minimum, one individual was collected at the Sherman Institute, Riverside County, CA. The human remains are hair clippings collected from one individual who was recorded as being 18 years old and identified as “Washoe.” Samuel H. Gilliam took the hair clippings at the Sherman Institute between 1930 and 1933. Gilliam sent the hair clippings to George Woodbury, who donated the hair clippings to the PMAE in 1935. No associated funerary objects are present.</P>
                <P>Human remains representing, at minimum, three individuals were collected at the Carson Indian School, Carson City County, NV. The human remains are hair clippings collected from one individual who was recorded as being 31 years old, one individual who was recorded as being 18 years old, and one individual who was recorded as being 17 years old. All individuals were identified as “Washoe.” Frederic Snyder took the hair clippings at the Carson Indian School between 1930 and 1933. Snyder sent the hair clippings to George Woodbury, who donated the hair clippings to the PMAE in 1935. No associated funerary objects are present.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: kinship and anthropological.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate lineal descendants, Indian Tribes, and Native Hawaiian organizations, the PMAE has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of four individuals of Native American ancestry.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains described in this notice and the Washoe Tribe of Nevada &amp; California (Carson Colony, Dresslerville Colony, Woodfords Community, Stewart Community, &amp; Washoe Ranches).</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the PMAE must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains are considered a single request and not competing requests. The PMAE is responsible for sending a copy of this notice to the Indian Tribe identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02557 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="8721"/>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037349; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Intent To Repatriate Cultural Items: University of California, Berkeley, Berkeley, CA</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the University of California, Berkeley intends to repatriate certain cultural items that meet the definition of objects of cultural patrimony and that have a cultural affiliation with the Indian Tribes in this notice. The cultural items were removed from Riverside County, CA.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the cultural items in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Alex Lucas, Repatriation Coordinator, University of California, Berkeley, Government and Community Relations, Office of the Chancellor, 120 California Hall, Berkeley, CA 94720, telephone (510) 570-0964, email 
                        <E T="03">nagpra-ucb@berkeley.edu.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the University of California, Berkeley. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the summary or related records held by the University of California, Berkeley.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>The two cultural items were removed from Temecula, Riverside County, CA. The two objects of cultural patrimony are baskets (catalog numbers 1-70106 and 1-10609). Basket 1-70106 was bequeathed to the Lowie Museum (Phoebe A. Hearst Museum of Anthropology) by Grace Blair DePue in 1945. Basket 1-10609 was “purchased at Capistrano from an old Indian woman named Martina Burvel” and is attributed to have originated in Temecula. The basket was then sold to Alfred Kroeber by Grace Nicholson of “Grace Nicholson Arts and Crafts Salesroom in Pasadena per Wells Fargo” and accessioned into the Lowie Museum (Phoebe A. Hearst Museum of Anthropology) in 1906.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The cultural items in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes. The following types of information were used to reasonably trace the relationship: geographical information and expert opinion (Native American traditional knowledge).</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the University of California, Berkeley has determined that:</P>
                <P>• The two cultural items described above have ongoing historical, traditional, or cultural importance central to the Native American group or culture itself, rather than property owned by an individual.</P>
                <P>
                    • There is a relationship of shared group identity that can be reasonably traced between the cultural items and the Pechanga Band of Indians (
                    <E T="03">previously</E>
                     listed as Pechanga Band of Luiseno Mission Indians of the Pechanga Reservation, California).
                </P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Additional, written requests for repatriation of the cultural items in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by any lineal descendant or Indian Tribe not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe.
                </P>
                <P>Repatriation of the cultural items in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the University of California, Berkeley must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the cultural items are considered a single request and not competing requests. The University of California, Berkeley is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3004, and the implementing regulations, 43 CFR 10.9.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02556 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037343; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Ohio History Connection, Columbus, OH</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Ohio History Connection has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Defiance County, OH.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nekole Alligood, NAGPRA Specialist, Ohio History Connection, 800 E 17th Avenue, Columbus, OH 43211, telephone (614) 297-2300, email 
                        <E T="03">nalligood@ohiohistory.org.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Ohio History Connection. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Ohio History Connection.
                    <PRTPAGE P="8722"/>
                </P>
                <HD SOURCE="HD1">Description</HD>
                <P>One individual, an adult female was collected from a riverbank in Defiance County, Ohio in 1992. Found with her were 47 small snail shells, two circular snail shells, one freshwater mussel shell fragment, and seven shell fragments (species unknown). All were found within the soil associated with this woman. The Lucas County Coroner's Office transferred this collection to the Ohio History Connection in 2019.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological information, geographical information, and indigenous knowledge from the consulting Tribes.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Ohio History Connection has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of one individual of Native American ancestry.</P>
                <P>• There are 57 objects described in this notice which are believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Absentee-Shawnee Tribe of Indians of Oklahoma; Bad River Band of the Lake Superior Tribe of Chippewa Indians of the Bad River Reservation, Wisconsin; Bay Mills Indian Community, Michigan; Cayuga Nation; Chippewa Cree Indians of the Rocky Boy's Reservation, Montana; Citizen Potawatomi Nation, Oklahoma; Delaware Nation, Oklahoma; Delaware Tribe of Indians; Eastern Shawnee Tribe of Oklahoma; Forest County Potawatomi Community, Wisconsin; Grand Traverse Band of Ottawa and Chippewa Indians, Michigan; Hannahville Indian Community, Michigan; Kaw Nation, Oklahoma; Keweenaw Bay Indian Community, Michigan; Kickapoo Traditional Tribe of Texas; Kickapoo Tribe of Indians of the Kickapoo Reservation in Kansas; Kickapoo Tribe of Oklahoma; Lac Courte Oreilles Band of Lake Superior Chippewa Indians of Wisconsin; Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin; Lac Vieux Desert Band of Lake Superior Chippewa Indians of Michigan; Little River Band of Ottawa Indians, Michigan; Little Shell Tribe of Chippewa Indians of Montana; Little Traverse Bay Bands of Odawa Indians, Michigan; Match-e-be-nash-she-wish Band of Pottawatomi Indians of Michigan; Miami Tribe of Oklahoma; Minnesota Chippewa Tribe, Minnesota (Six component reservations: Bois Forte Band (Nett Lake); Fond du Lac Band; Grand Portage Band; Leech Lake Band; Mille Lacs Band; White Earth Band); Nottawaseppi Huron Band of the Potawatomi, Michigan; Omaha Tribe of Nebraska; Oneida Indian Nation; Oneida Nation; Onondaga Nation; Ottawa Tribe of Oklahoma; Peoria Tribe of Indians of Oklahoma; Pokagon Band of Potawatomi Indians, Michigan and Indiana; Ponca Tribe of Indians of Oklahoma; Ponca Tribe of Nebraska; Prairie Band Potawatomi Nation; Red Cliff Band of Lake Superior Chippewa Indians of Wisconsin; Red Lake Band of Chippewa Indians, Minnesota; Saginaw Chippewa Indian Tribe of Michigan; Saint Regis Mohawk Tribe; Sault Ste. Marie Tribe of Chippewa Indians, Michigan; Seneca Nation of Indians; Seneca-Cayuga Nation; Shawnee Tribe; Sokaogon Chippewa Community, Wisconsin; St. Croix Chippewa Indians of Wisconsin; Tonawanda Band of Seneca; Turtle Mountain Band of Chippewa Indians of North Dakota; Tuscarora Nation; and the Wyandotte Nation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Ohio History Connection must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Ohio History Connection is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02551 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037351; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Intent To Repatriate Cultural Items: Goucher College, Baltimore, MD</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), Goucher College intends to repatriate certain cultural items that meet the definition of objects of cultural patrimony and that have a cultural affiliation with the Indian Tribes or Native Hawaiian organizations in this notice. The thirteen cultural items were removed from areas in the present-day states of New Mexico and Arizona.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the cultural items in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Elaine Meyer-Lee, Provost, Goucher College, 1021 Dulaney Valley Road, Baltimore, MD 21204, telephone (410) 337-6044, email 
                        <E T="03">Elaine.Meyer-Lee@goucher.edu.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This notice is published as part of the National Park Service's administrative 
                    <PRTPAGE P="8723"/>
                    responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of Goucher College. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the summary or related records held by Goucher College.
                </P>
                <HD SOURCE="HD1">Description</HD>
                <P>The 13 cultural items were removed from areas in the present-day states of New Mexico and Arizona in the late nineteenth and early twentieth centuries. They were gathered by John Franklin Goucher and other Methodist missionaries who toured the western United States and who were friends of John Goucher, one of the founders of the Woman's College of Baltimore, later known as Goucher College. John Goucher donated his collection of Native American cultural items to Goucher College in 1921. The 13 objects of cultural patrimony are seven jars, two bowls, three pitchers, and one pot.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The cultural items in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: geographical information; historical information; expert opinion.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, Goucher College has determined that:</P>
                <P>• The 13 cultural items described above have ongoing historical, traditional, or cultural importance central to the Native American group or culture itself, rather than property owned by an individual.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the cultural items and the Zuni Tribe of the Zuni Reservation, New Mexico.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Additional, written requests for repatriation of the cultural items in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.
                </P>
                <P>Repatriation of the cultural items in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, Goucher College will determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the cultural items are considered a single request and not competing requests. Goucher College is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3004, and the implementing regulations, 43 CFR 10.9.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02558 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>National Park Service</SUBAGY>
                <DEPDOC>[NPS-WASO-NAGPRA-NPS0037347; PPWOCRADN0-PCU00RP14.R50000]</DEPDOC>
                <SUBJECT>Notice of Inventory Completion: Ohio History Connection, Columbus, OH</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Park Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Native American Graves Protection and Repatriation Act (NAGPRA), the Ohio History Connection has completed an inventory of human remains and associated funerary objects and has determined that there is a cultural affiliation between the human remains and associated funerary objects and Indian Tribes or Native Hawaiian organizations in this notice. The human remains and associated funerary objects were removed from Lucas County, Ohio.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Repatriation of the human remains and associated funerary objects in this notice may occur on or after March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nekole Alligood, NAGPRA Specialist, Ohio History Connection, 800 E. 17th Avenue, Columbus, OH 43211, telephone (614) 297-2300, email 
                        <E T="03">nalligood@ohiohistory.org</E>
                        .
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published as part of the National Park Service's administrative responsibilities under NAGPRA. The determinations in this notice are the sole responsibility of the Ohio History Connection. The National Park Service is not responsible for the determinations in this notice. Additional information on the determinations in this notice, including the results of consultation, can be found in the inventory or related records held by the Ohio History Connection.</P>
                <HD SOURCE="HD1">Description</HD>
                <P>Human remains representing at minimum 33 individuals were removed from various sites in Lucas County, Ohio.</P>
                <P>33 LU 788, Indian Island, Waterville Township, Lucas County, Ohio. Two adult individuals were recovered and 97 associated funerary objects were found eroding out on Indian Island in the Maumee River on Ohio Department of Natural Resources property in 2010 and again in 2017 and were transferred to the Ohio History Connection.</P>
                <P>Toledo, Lucas County, Ohio; remains of one individual received by the Lucas County Coroner's Office in 1994 and determined as not modern. The site was excavated in the 1970s and the individual's remains were transferred to Ohio History Connection in 2019.</P>
                <P>Eight individuals who had been moved from their original resting places for the construction of a home in 1900 along the Ottawa River Road (now known as Park Place neighborhood). The same group of eight were exhumed again upon the demolition of the 1900 house in preparation for a new home in 2019. They were taken to the Lucas County Coroner's Office and then transferred to Ohio History Connection in 2019. There are 29 associated funerary objects removed from the site including nine nails and nail fragments, 16 metal fragments, one screw, one wire/metal earring, one wood fragment, and one bluish-white bead.</P>
                <P>
                    33 LU 165 “Fry Site,” Toledo, Washington Township, Lucas County, Ohio. Seventeen individuals were exhumed in 1977 and donated to the Firelands Archaeological Research Center who then donated them to the Ohio History Connection for NAGPRA processing. The site is located on the 
                    <PRTPAGE P="8724"/>
                    west bank of the Maumee on the floodplain in Toledo, Ohio and was noted as an “Indian farmstead.” There are 11 adults, five juveniles and one toddler or infant. Associated funerary objects consist of two silver armbands, one silver gorget, one bead necklace, one knife, one pipe fragment, faunal remains, debitage and unmodified rock, fire cracked rock, one sherd, one metal fastener, one scraper, one cobble, and burned wood fragments.
                </P>
                <P>33 LU 30, Haberstock Site, Providence Township, Lucas County, Ohio. Five individuals were removed from the site in 1967 and were donated to Firelands Archaeological Research Center and then donated to the Ohio History Connection in 2021. The site is located on the shore of the Maumee River north of Woodcock and Indian Islands. There are three adults and two juveniles. The associated funerary objects consist of debitage, one sherd, faunal remains, fire cracked rock, and metal fragments.</P>
                <HD SOURCE="HD1">Cultural Affiliation</HD>
                <P>The human remains and associated funerary objects in this notice are connected to one or more identifiable earlier groups, tribes, peoples, or cultures. There is a relationship of shared group identity between the identifiable earlier groups, tribes, peoples, or cultures and one or more Indian Tribes or Native Hawaiian organizations. The following types of information were used to reasonably trace the relationship: archeological information, geographical information, and indigenous knowledge from the consulting Tribes.</P>
                <HD SOURCE="HD1">Determinations</HD>
                <P>Pursuant to NAGPRA and its implementing regulations, and after consultation with the appropriate Indian Tribes and Native Hawaiian organizations, the Ohio History Connection has determined that:</P>
                <P>• The human remains described in this notice represent the physical remains of 33 individuals of Native American ancestry.</P>
                <P>• The 169 objects described in this notice are reasonably believed to have been placed with or near individual human remains at the time of death or later as part of the death rite or ceremony.</P>
                <P>• There is a relationship of shared group identity that can be reasonably traced between the human remains and associated funerary objects described in this notice and the Absentee-Shawnee Tribe of Indians of Oklahoma; Bad River Band of the Lake Superior Tribe of Chippewa Indians of the Bad River Reservation, Wisconsin; Bay Mills Indian Community, Michigan; Cayuga Nation; Chippewa Cree Indians of the Rocky Boy's Reservation, Montana; Citizen Potawatomi Nation, Oklahoma; Delaware Nation, Oklahoma; Delaware Tribe of Indians; Eastern Shawnee Tribe of Oklahoma; Forest County Potawatomi Community, Wisconsin; Grand Traverse Band of Ottawa and Chippewa Indians, Michigan; Hannahville Indian Community, Michigan; Kaw Nation, Oklahoma; Keweenaw Bay Indian Community, Michigan; Kickapoo Traditional Tribe of Texas; Kickapoo Tribe of Indians of the Kickapoo Reservation in Kansas; Kickapoo Tribe of Oklahoma; Lac Courte Oreilles Band of Lake Superior Chippewa Indians of Wisconsin; Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin; Lac Vieux Desert Band of Lake Superior Chippewa Indians of Michigan; Little River Band of Ottawa Indians, Michigan; Little Shell Tribe of Chippewa Indians of Montana; Little Traverse Bay Bands of Odawa Indians, Michigan; Match-e-be-nash-she-wish Band of Pottawatomi Indians of Michigan; Miami Tribe of Oklahoma; Minnesota Chippewa Tribe, Minnesota (Six component reservations: Bois Forte Band (Nett Lake); Fond du Lac Band; Grand Portage Band; Leech Lake Band; Mille Lacs Band; White Earth Band); Nottawaseppi Huron Band of the Potawatomi, Michigan; Omaha Tribe of Nebraska; Oneida Indian Nation; Oneida Nation; Onondaga Nation; Ottawa Tribe of Oklahoma; Peoria Tribe of Indians of Oklahoma; Pokagon Band of Potawatomi Indians, Michigan and Indiana; Ponca Tribe of Indians of Oklahoma; Ponca Tribe of Nebraska; Prairie Band Potawatomi Nation; Red Cliff Band of Lake Superior Chippewa Indians of Wisconsin; Red Lake Band of Chippewa Indians, Minnesota; Sac &amp; Fox Nation of Missouri in Kansas and Nebraska; Sac &amp; Fox Nation, Oklahoma; Sac &amp; Fox Tribe of the Mississippi in Iowa; Saginaw Chippewa Indian Tribe of Michigan; Saint Regis Mohawk Tribe; Sault Ste. Marie Tribe of Chippewa Indians, Michigan; Seneca Nation of Indians; Seneca-Cayuga Nation; Shawnee Tribe; Sokaogon Chippewa Community, Wisconsin; St. Croix Chippewa Indians of Wisconsin; Tonawanda Band of Seneca; Turtle Mountain Band of Chippewa Indians of North Dakota; Tuscarora Nation; and the Wyandotte Nation.</P>
                <HD SOURCE="HD1">Requests for Repatriation</HD>
                <P>
                    Written requests for repatriation of the human remains and associated funerary objects in this notice must be sent to the Responsible Official identified in 
                    <E T="02">ADDRESSES</E>
                    . Requests for repatriation may be submitted by:
                </P>
                <P>1. Any one or more of the Indian Tribes or Native Hawaiian organizations identified in this notice.</P>
                <P>2. Any lineal descendant, Indian Tribe, or Native Hawaiian organization not identified in this notice who shows, by a preponderance of the evidence, that the requestor is a lineal descendant or a culturally affiliated Indian Tribe or Native Hawaiian organization.</P>
                <P>Repatriation of the human remains and associated funerary objects in this notice to a requestor may occur on or after March 11, 2024. If competing requests for repatriation are received, the Ohio History Connection must determine the most appropriate requestor prior to repatriation. Requests for joint repatriation of the human remains and associated funerary objects are considered a single request and not competing requests. The Ohio History Connection is responsible for sending a copy of this notice to the Indian Tribes and Native Hawaiian organizations identified in this notice.</P>
                <P>
                    This notice was submitted on or after the effective date of the revised regulations (88 FR 86452, December 13, 2023, effective January 12, 2024). As the notice conforms to the mandatory format of the 
                    <E T="04">Federal Register</E>
                     and includes the required information, the National Park Service is publishing this notice as submitted.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Native American Graves Protection and Repatriation Act, 25 U.S.C. 3003, and the implementing regulations, 43 CFR 10.10.
                </P>
                <SIG>
                    <DATED>Dated: February 1, 2024.</DATED>
                    <NAME>Melanie O'Brien,</NAME>
                    <TITLE>Manager, National NAGPRA Program.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02554 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4312-52-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NATIONAL ARCHIVES AND RECORDS ADMINISTRATION</AGENCY>
                <DEPDOC>[NARA-2024-014]</DEPDOC>
                <SUBJECT>State, Local, Tribal, and Private Sector Policy Advisory Committee (SLTPS-PAC); Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Information Security Oversight Office (ISOO), National Archives and Records Administration (NARA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of Federal advisory committee meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        We are announcing an upcoming meeting of the State, Local, Tribal, and Private Sector Policy Advisory Committee (SLTPS-PAC) in accordance with the Federal Advisory 
                        <PRTPAGE P="8725"/>
                        Committee Act and implementing regulations.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be on February 21, 2024, from 10 a.m. to 11 a.m. (EST).</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>This meeting will be a virtual meeting. We will send instructions on how to access the meeting to those who register according to the instructions below.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Heather Harris Pagán, ISOO Senior Program Analyst, at 
                        <E T="03">SLTPS_PAC@nara.gov</E>
                         or (202) 357-5351. Contact ISOO at 
                        <E T="03">ISOO@nara.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This meeting is open to the public in accordance with the Federal Advisory Committee Act (5 U.S.C. app 2) and implementing regulations at 41 CFR 102-3. The Committee will discuss matters relating to the classified national security information program for state, local, tribal, and private sector entities.</P>
                <P>
                    <E T="03">Procedures:</E>
                     Please submit the name, email address, and telephone number of people planning to attend to Heather Harris Pagán at ISOO (contact information above) no later than February 20, 2024. We will provide meeting access information to those who register.
                </P>
                <SIG>
                    <NAME>Merrily Harris,</NAME>
                    <TITLE>Committee Management Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02529 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7515-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket Nos. 50-259, 50-260, and 50-296; NRC-2024-0030]</DEPDOC>
                <SUBJECT>Tennessee Valley Authority; Browns Ferry Nuclear Plant, Units 1, 2, and 3; Subsequent License Renewal Application</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; receipt.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) has received an application for the subsequent renewal of Renewed Facility Operating License Nos. DPR-33, DPR-52, and DPR-68, which authorize Tennessee Valley Authority (TVA, the applicant) to operate Browns Ferry Nuclear Plant (BFN), Units 1, 2, and 3. The subsequent renewed licenses would authorize the applicant to operate BFN for an additional 20 years beyond the period specified in each of the current licenses. The current operating licenses for BFN expire as follows: Unit 1 on December 20, 2033, Unit 2 on June 28, 2034, and Unit 3 on July 2, 2036.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The subsequent license renewal application referenced in this document was available as of January 19, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Please refer to Docket ID NRC-2024-0030 when contacting the NRC about the availability of information regarding this document. You may obtain publicly available information related to this document using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal Rulemaking website:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and search for Docket ID NRC-2024-0030. Address questions about Docket IDs in 
                        <E T="03">Regulations.gov</E>
                         to Stacy Schumann; telephone: 301-415-0624; email: 
                        <E T="03">Stacy.Schumann@nrc.gov</E>
                        . For technical questions, contact the individual listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section of this document.
                    </P>
                    <P>
                        • 
                        <E T="03">NRC's Agencywide Documents Access and Management System (ADAMS):</E>
                         You may obtain publicly available documents online in the ADAMS Public Documents collection at 
                        <E T="03">https://www.nrc.gov/reading-rm/adams.html</E>
                        . To begin the search, select “Begin Web-based ADAMS Search.” For problems with ADAMS, please contact the NRC's Public Document Room (PDR) reference staff at 1-800-397-4209, at 301-415-4737, or by email to 
                        <E T="03">PDR.Resource@nrc.gov</E>
                        . The ADAMS accession number for each document referenced (if it is available in ADAMS) is provided the first time that it is mentioned in this document.
                    </P>
                    <P>
                        • 
                        <E T="03">Public Library:</E>
                         A copy of the subsequent license renewal application for BFN can be accessed at the following public library: Athens-Limestone County Public Library, 603 S Jefferson St, Athens, AL 35611.
                    </P>
                    <P>
                        • 
                        <E T="03">NRC's PDR:</E>
                         The PDR, where you may examine and order copies of publicly available documents, is open by appointment. To make an appointment to visit the PDR, please send an email to 
                        <E T="03">PDR.Resource@nrc.gov</E>
                         or call 1-800-397-4209 or 301-415-4737, between 8 a.m. and 4 p.m. eastern time (ET), Monday through Friday, except Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jessica Hammock, Office of Nuclear Reactor Regulation, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-0740; email: 
                        <E T="03">Jessica.Hammock@nrc.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The NRC has received an application (ADAMS Accession No. ML24019A010) from TVA, dated January 19, 2024, filed pursuant to section 103 of the Atomic Energy Act of 1954, as amended, and part 54 of title 10 of the 
                    <E T="03">Code of Federal Regulations,</E>
                     “Requirements for Renewal of Operating Licenses for Nuclear Power Plants,” to renew the operating licenses for BFN, Units 1, 2, and 3. Subsequent renewal of the licenses would authorize the applicant to operate the facility for an additional 20-year period beyond the period specified in the respective current operating licenses. The current operating licenses for BFN expire as follows: Unit 1 on December 20, 2033, Unit 2 on June 28, 2034, and Unit 3 on July 2, 2036. The BFN units are boiling water reactors located in Athens, Alabama. The acceptability of the tendered application for docketing, and other matters, including an opportunity to request a hearing, will be the subject of subsequent 
                    <E T="04">Federal Register</E>
                     notices.
                </P>
                <P>A copy of the subsequent license renewal application for BFN, Units 1, 2, and 3, is also available to local residents near the site at the following public library: Athens-Limestone County Public Library, 603 S Jefferson St., Athens, AL 35611.</P>
                <SIG>
                    <DATED>Dated: February 5, 2024.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>Lauren K. Gibson,</NAME>
                    <TITLE>Chief, License Renewal Project Branch, Division of New and Renewed Licenses, Office of Nuclear Reactor Regulation.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02611 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">PENSION BENEFIT GUARANTY CORPORATION</AGENCY>
                <SUBJECT>Proposed Submission of Information Collection for OMB Review; Comment Request; Locating and Paying Participants</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Pension Benefit Guaranty Corporation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of intent to request extension of OMB approval of an information collection.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Pension Benefit Guaranty Corporation (PBGC) intends to request that the Office of Management and Budget (OMB) extend approval of a collection of information (OMB Control Number 1212-0055; expires August 31, 2024) under the Paperwork Reduction Act. The purpose of the information collection is to enable PBGC to pay benefits to participants and beneficiaries. This notice informs the public of PBGC's request and solicits public comment on the collection.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before April 8, 2024 to be assured of consideration.</P>
                </DATES>
                <ADD>
                    <PRTPAGE P="8726"/>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Comments may be submitted by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal: http://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Email: paperwork.comments@pbgc.gov.</E>
                         Refer to Locating and Paying Participants in the subject line.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail or Hand Delivery:</E>
                         Regulatory Affairs Division, Office of the General Counsel, Pension Benefit Guaranty Corporation, 445 12th Street SW, Washington, DC 20024-2101.
                    </P>
                    <P>Commenters are strongly encouraged to submit comments electronically. Commenters who submit comments on paper by mail should allow sufficient time for mailed comments to be received before the close of the comment period.</P>
                    <P>
                        All submissions received must include the agency's name (Pension Benefit Guaranty Corporation, or PBGC) and refer to Locating and Paying Participants. All comments received will be posted without change to PBGC's website, 
                        <E T="03">http://www.pbgc.gov,</E>
                         including any personal information provided. Do not submit comments that include any personally identifiable information or confidential business information.
                    </P>
                    <P>
                        Copies of the collection of information may be obtained without charge by writing to the Disclosure Division, (
                        <E T="03">disclosure@pbgc.gov</E>
                        ), Office of the General Counsel, Pension Benefit Guaranty Corporation, 445 12th Street SW, Washington, DC 20024-2101; or, calling 202-229-4040 during normal business hours. If you are deaf or hard of hearing, or have a speech disability, please dial 7-1-1 to access telecommunications relay services.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Monica O'Donnell (
                        <E T="03">odonnell.monica@pbgc.gov</E>
                        ), Attorney, Regulatory Affairs Division, Office of the General Counsel, Pension Benefit Guaranty Corporation, 445 12th Street SW, Washington, DC 20024-2101; 202-229-8706; or Gregory Katz (
                        <E T="03">katz.gregory@pbgc.gov</E>
                        ), Attorney, Regulatory Affairs Division, Office of the General Counsel, Pension Benefit Guaranty Corporation, 445 12th Street SW, Washington, DC 20024-2101; 202-229-3829. If you are deaf or hard of hearing, or have a speech disability, please dial 7-1-1 to access telecommunications relay services.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This information collection is needed to pay participants and beneficiaries who may be entitled to pension benefits from plans that have terminated. Participants and beneficiaries are asked to provide information in connection with an application for benefits. This includes requests to individuals to provide identifying information so that PBGC may determine whether the individuals are entitled to benefits. All requested information is needed so that PBGC may determine benefit entitlements and make appropriate payments.</P>
                <P>
                    This information collection includes My Pension Benefit Account (MyPBA), an application on PBGC's website, 
                    <E T="03">http://www.pbgc.gov,</E>
                     through which plan participants and beneficiaries may conduct electronic transactions with PBGC, including applying for pension benefits, designating a beneficiary, changing contact information, and applying for or changing electronic direct deposit.
                </P>
                <P>PBGC is proposing the addition of three new forms: Form 713RBD, Form 714RBD, and Form 721RBD. Form 713RBD and Form 714RBD relate to elections to withdraw employee contributions for participants and beneficiaries who are at or beyond their Required Beginning Dates. Form 721RBD relates to elections of single payments for non-spouse beneficiaries who are at or beyond their Required Beginning Dates. PBGC is proposing to remove Form 718, “Installment Payment Agreement,” because PBGC no longer administers installment agreements for benefit overpayments. PBGC is proposing to remove Form 719 for electing or changing tax withholding from annuity benefit payments since participants are using Internal Revenue Service (IRS) Form W-4P, “Withholding Certificate for Periodic Pension or Annuity Payments.” PBGC is also making other clarifying, editorial, and formatting changes.</P>
                <P>The existing collection of information was approved through August 31, 2024, under OMB control number 1212-0055. PBGC intends to request that OMB extend its approval (with modifications) for three years. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>PBGC estimates that it will receive a combined 136,081 benefit applications and information forms annually. The total annual burden associated with this collection of information is estimated to be 101,571 hours and an estimated $60,742 (the estimated cost of notary services for signatures (including spousal consents) required on applicable forms).</P>
                <P>PBGC is soliciting public comments to—</P>
                <P>• 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;</P>
                <P>• Evaluate the accuracy of the agency's estimate of the burden of the proposed collection of information, including the validity of the methodologies and assumptions used;</P>
                <P>• Enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>• Minimize the burden of the collection of information on those who are to respond,</P>
                <P>
                    including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of responses.
                </P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>Stephanie Cibinic,</NAME>
                    <TITLE>Deputy Assistant General Counsel for Regulatory Affairs, Pension Benefit Guaranty Corporation.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02518 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7709-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">POSTAL REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket Nos. MC2024-180 and CP2024-186; MC2024-181 and CP2024-187]</DEPDOC>
                <SUBJECT>New Postal Products</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Postal Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>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.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments are due:</E>
                         February 12, 2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit comments electronically via the Commission's Filing Online system at 
                        <E T="03">http://www.prc.gov.</E>
                         Those who cannot submit comments electronically should contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section by telephone for advice on filing alternatives.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>David A. Trissell, General Counsel, at 202-789-6820.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Introduction</FP>
                    <FP SOURCE="FP-2">II. Docketed Proceeding(s)</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>
                    The Commission gives notice that the Postal Service filed request(s) for the 
                    <PRTPAGE P="8727"/>
                    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.
                </P>
                <P>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.</P>
                <P>
                    The public portions of the Postal Service's request(s) can be accessed via the Commission's website (
                    <E T="03">http://www.prc.gov</E>
                    ). Non-public portions of the Postal Service's request(s), if any, can be accessed through compliance with the requirements of 39 CFR 3011.301.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Docket No. RM2018-3, Order Adopting Final Rules Relating to Non-Public Information, June 27, 2018, Attachment A at 19-22 (Order No. 4679).
                    </P>
                </FTNT>
                <P>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.</P>
                <HD SOURCE="HD1">II. Docketed Proceeding(s)</HD>
                <P>
                    1. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-180 and CP2024-186; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express International, Priority Mail International &amp; First-Class Package International Service Contract 36 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 2, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Samuel Robinson; 
                    <E T="03">Comments Due:</E>
                     February 12, 2024.
                </P>
                <P>
                    2. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-181 and CP2024-187; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail &amp; USPS Ground Advantage Contract 183 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 2, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Almaroof Agoro; 
                    <E T="03">Comments Due:</E>
                     February 12, 2024.
                </P>
                <P>
                    This Notice will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <NAME>Jennie L. Jbara,</NAME>
                    <TITLE>Alternate Certifying Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02618 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-FW-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket No. MC2024-175; CP2024-181; MC2024-176; CP2024-182; MC2024-177; CP2024-183; MC2024-178; CP2024-184; MC2024-179; CP2024-185]</DEPDOC>
                <SUBJECT>New Postal Products</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Postal Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>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.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments are due:</E>
                         February 9, 2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit comments electronically via the Commission's Filing Online system at 
                        <E T="03">http://www.prc.gov</E>
                        . Those who cannot submit comments electronically should contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section by telephone for advice on filing alternatives.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>David A. Trissell, General Counsel, at 202-789-6820.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Introduction</FP>
                    <FP SOURCE="FP-2">II. Docketed Proceeding(s)</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>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.</P>
                <P>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.</P>
                <P>
                    The public portions of the Postal Service's request(s) can be accessed via the Commission's website (
                    <E T="03">http://www.prc.gov</E>
                    ). Non-public portions of the Postal Service's request(s), if any, can be accessed through compliance with the requirements of 39 CFR 3011.301.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Docket No. RM2018-3, Order Adopting Final Rules Relating to Non-Public Information, June 27, 2018, Attachment A at 19-22 (Order No. 4679).
                    </P>
                </FTNT>
                <P>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.</P>
                <HD SOURCE="HD1">II. Docketed Proceeding(s)</HD>
                <P>
                    1. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-175 and CP2024-181; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail, USPS Ground Advantage &amp; Parcel Select Contract 4 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 1, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Alireza Motameni; 
                    <E T="03">Comments Due:</E>
                     February 9, 2024.
                </P>
                <P>
                    2. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-176 and CP2024-182; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail &amp; USPS Ground Advantage Contract 180 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 1, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <PRTPAGE P="8728"/>
                    <E T="03">Public Representative:</E>
                     Almaroof Agoro; 
                    <E T="03">Comments Due:</E>
                     February 9, 2024.
                </P>
                <P>
                    3. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-177 and CP2024-183; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 45 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 1, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Alain Richard Brou; 
                    <E T="03">Comments Due:</E>
                     February 9, 2024.
                </P>
                <P>
                    4. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-178 and CP2024-184; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail &amp; USPS Ground Advantage Contract 181 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 1, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Cherry Yao; 
                    <E T="03">Comments Due:</E>
                     February 9, 2024.
                </P>
                <P>
                    5. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-179 and CP2024-185; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail &amp; USPS Ground Advantage Contract 182 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     February 1, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Jennaca D. Upperman; 
                    <E T="03">Comments Due:</E>
                     February 9, 2024.
                </P>
                <P>
                    This Notice will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <NAME>Jennie L. Jbara,</NAME>
                    <TITLE>Alternate Certifying Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02527 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-FW-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail Express, Priority Mail, and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean C. Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 1, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage® Contract 45 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-177, CP2024-183.
                </P>
                <SIG>
                    <NAME>Sean C. Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02538 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on January 29, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 176 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-169, CP2024-175.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02540 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail Express, Priority Mail, USPS Ground Advantage®, and Parcel Select Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean C. Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on January 30, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail Express, Priority Mail, USPS Ground Advantage®, and Parcel Select Contract 4 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-174, CP2024-180.
                </P>
                <SIG>
                    <NAME>Sean C. Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02533 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on January 30, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 179 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-172, CP2024-178.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02532 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <PRTPAGE P="8729"/>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on January 30, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 177 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-170, CP2024-176.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02542 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 1, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 181 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-178, CP2024-184.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02531 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail, USPS Ground Advantage® &amp; Parcel Select Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 1, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail, USPS Ground Advantage® &amp; Parcel Select Contract 4 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-175, CP2024-181.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02535 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 1, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 180 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-176, CP2024-182.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02534 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 2, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 183 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-181, CP2024-187.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02541 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 
                    <PRTPAGE P="8730"/>
                    3642 and 3632(b)(3), on January 30, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 178 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-171, CP2024-177.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02537 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on February 1, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail &amp; USPS Ground Advantage® Contract 182 to Competitive Product List</E>
                    . Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-179, CP2024-185.
                </P>
                <SIG>
                    <NAME>Sean Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02530 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">POSTAL SERVICE</AGENCY>
                <SUBJECT>Product Change—Priority Mail Express, Priority Mail, and USPS Ground Advantage® Negotiated Service Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>
                        Postal Service
                        <E T="51">TM</E>
                        .
                    </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Postal Service gives notice of filing a request with the Postal Regulatory Commission to add a domestic shipping services contract to the list of Negotiated Service Agreements in the Mail Classification Schedule's Competitive Products List.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date of required notice:</E>
                         February 8, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Sean C. Robinson, 202-268-8405.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The United States Postal Service® hereby gives notice that, pursuant to 39 U.S.C. 3642 and 3632(b)(3), on January 30, 2024, it filed with the Postal Regulatory Commission a 
                    <E T="03">USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage® Contract 44 to Competitive Product List.</E>
                     Documents are available at 
                    <E T="03">www.prc.gov,</E>
                     Docket Nos. MC2024-173, CP2024-179.
                </P>
                <SIG>
                    <NAME>Sean C. Robinson,</NAME>
                    <TITLE>Attorney, Corporate and Postal Business Law.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02543 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-99462; File No. SR-FICC-2024-002]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; Fixed Income Clearing Corporation; Notice of Filing and Immediate Effectiveness of Proposed Rule Change to Clarify How FICC Applies the Minimum Charge</SUBJECT>
                <DATE>February 2, 2024.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (“Act”) 
                    <SU>1</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>2</SU>
                    <FTREF/>
                     notice is hereby given that on January 25, 2024, Fixed Income Clearing Corporation (“FICC”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I, II and III below, which Items have been prepared by the clearing agency. FICC filed the proposed rule change pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>3</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(4) thereunder.
                    <SU>4</SU>
                    <FTREF/>
                     The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         15 U.S.C. 78s(b)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         17 CFR 240.19b-4(f)(4).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Clearing Agency's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The proposed rule change consists of modifications to the FICC Mortgage-Backed Securities Division (“MBSD”) Clearing Rules (“MBSD Rules”) to clarify how FICC applies the Minimum Charge (as defined below) at MBSD, as well as make certain technical changes, as described in greater detail below.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         Capitalized terms used herein and not defined shall have the meaning assigned to such terms in the MBSD Rules, 
                        <E T="03">available at www.dtcc.com/legal/rules-and-procedures.aspx.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Clearing Agency's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the clearing agency 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 clearing agency has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">(A) Clearing Agency's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>FICC is proposing changes that would clarify the disclosures in the MBSD Rules related to FICC's application of Minimum Charge at MBSD.</P>
                <HD SOURCE="HD3">Background</HD>
                <P>
                    As part of its market risk management strategy, FICC manages its credit exposure to Clearing Members by determining the appropriate Required Fund Deposit to the Clearing Fund and monitoring its sufficiency, as provided for in the MBSD Rules.
                    <SU>6</SU>
                    <FTREF/>
                     The Required Fund Deposit serves as each Clearing Member's margin. The objective of a Clearing Member's Required Fund Deposit is to mitigate potential losses to FICC associated with liquidation of a Clearing Member's portfolio in the event FICC ceases to act for that Clearing Member (hereinafter referred to as a “default”).
                    <SU>7</SU>
                    <FTREF/>
                     The aggregate of all Clearing Member's Required Fund Deposits, together with certain other deposits required under the MBSD Rules, constitutes the Clearing Fund, which FICC would access, among other instances, should a defaulting Clearing Member's own Clearing Fund deposit be insufficient to satisfy losses to FICC caused by the liquidation of that Clearing Member's portfolio.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         MBSD Rule 4 (Clearing Fund and Loss Allocation), 
                        <E T="03">supra</E>
                         note 5. FICC's market risk management strategy is designed to comply with Rule 17Ad-22(e)(4) under the Act, where these risks are referred to as “credit risks.” 17 CFR 240.17Ad-22(e)(4).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         MBSD Rule 17 (Procedures for When the Corporation Ceases to Act), 
                        <E T="03">supra</E>
                         note 5.
                    </P>
                </FTNT>
                <P>
                    Pursuant to the MBSD Rules, each Clearing Member's Required Fund Deposit amount consists of a number of 
                    <PRTPAGE P="8731"/>
                    applicable components, each of which is designed to address specific risks faced by FICC, as identified within MBSD Rule 4.
                    <SU>8</SU>
                    <FTREF/>
                     Specifically, MBSD Rule 4, Section 2(b) currently states that each Clearing Member's Required Fund Deposit amount consists of the greater of (i) the Minimum Charge 
                    <SU>9</SU>
                    <FTREF/>
                     or (ii) the sum of the following components: the VaR Charge, the six days' interest for Fails item, a special charge (to the extent determined by FICC to be appropriate),
                    <SU>10</SU>
                    <FTREF/>
                     and, if applicable, the Backtesting Charge, Holiday Charge, Intraday Mark-to-Market Charge, Intraday VaR Charge, and the Margin Liquidity Adjustment Charge.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         MBSD Rule 4. 
                        <E T="03">Supra</E>
                         note 5.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         Section 2(b) of MBSD Rule 4 provides the Minimum Charge for each margin portfolio of a Clearing Member shall be no less than $100,000, and the Minimum Charge for each margin portfolio of an Unregistered Investment Pool Clearing Member shall be no less than $1 million.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         In order to mitigate exposure from certain market conditions and other financial and operational capabilities of a Clearing Member, FICC may impose a special charge.
                    </P>
                </FTNT>
                <P>Some of these components are calculated at the margin portfolio level while other components are calculated at the member level. In particular, the Minimum Charge, the VaR Charge and the six days' interest for Fails item are calculated for each margin portfolio of a Clearing Member, while the special charge and, if applicable, the Backtesting Charge, Holiday Charge, Intraday Mark-to-Market Charge, Intraday VaR Charge, and the Margin Liquidity Adjustment Charge are assessed with respect to each Clearing Member.</P>
                <P>
                    Given that these components are calculated at varying levels, 
                    <E T="03">i.e.,</E>
                     margin portfolio level vs. member level, FICC currently follows a two-step process when determining the Required Fund Deposit amount for a Clearing Member. Specifically, when calculating the Required Fund Deposit amount for a Clearing Member, FICC first assesses the applicable charge with respect to each and every margin portfolio of the Clearing Member. FICC determines whether or not to apply the Minimum Charge to the margin portfolio by comparing (i) the relevant Minimum Charge for the margin portfolio with (ii) the sum of the VaR Charge and the six days' interest for Fails item of the margin portfolio. FICC only applies the Minimum Charge as the applicable charge for a margin portfolio when the Minimum Charge for the margin portfolio exceeds the sum of the VaR Charge and the six days' interest for Fails item of the margin portfolio, otherwise FICC uses the sum of the VaR Charge and the six days' interest for Fails item of the margin portfolio as the applicable charge for the margin portfolio.
                </P>
                <P>
                    After FICC assesses the applicable charge with respect to each and every margin portfolio of the Clearing Member, FICC aggregates these charges and add the components that are calculated at the member level, 
                    <E T="03">i.e.,</E>
                     special charge, if any, and, if applicable, the Backtesting Charge, Holiday Charge, Intraday Mark-to-Market Charge, Intraday VaR Charge, and the Margin Liquidity Adjustment Charge, to determine the Required Fund Deposit amount of the Clearing Member.
                </P>
                <HD SOURCE="HD3">Proposed Rule Changes</HD>
                <P>In order to better reflect FICC's current process in determining the Required Fund Deposit amount of a Clearing Member, particularly with respect to FICC's application of Minimum Charge, FICC is proposing the following clarifying rule changes.</P>
                <P>Specifically, FICC is proposing to revise the Minimum Margin definition in the MBSD Rule 1 (Definitions) to state the term “Minimum Charge” means the minimum amount of required deposit to the Clearing Fund with respect to each margin portfolio of a Clearing Member. FICC is proposing this change to make it clearer that the Minimum Margin is determined with respect to each and every margin portfolio of a Clearing Member.</P>
                <P>FICC is also proposing to modify the definition of the Required Fund Deposit in MBSD Rule 1 to make it clearer that Required Fund Deposit means the amount of each Clearing Member's required deposit to the Clearing Fund as determined by the FICC pursuant to Section 2 of Rule 4 and other applicable Rules.</P>
                <P>In addition, FICC is proposing to revise Section 2 of MBSD Rule 4 (Clearing Fund and Loss Allocation) to more clearly delineate components that are calculated at the margin portfolio level versus those that are calculated at the member level when determining the Required Fund Deposit amount of each Clearing Member. Furthermore, FICC is proposing language to clarify that, when determining the amount of Required Fund Deposit with respect to each margin portfolio of a Clearing Member, FICC would use an amount equal to the greater of (i) the Minimum Charge and (ii) the sum of the VaR Charge and the six days' interest for Fails item of the margin portfolio.</P>
                <P>To further enhance the clarity of MBSD Rules, FICC is also proposing a number of technical changes and one conforming change.</P>
                <P>These proposed rule changes are intended to better reflect FICC's current process in determining the Required Fund Deposit amount of a Clearing Member but would not change the Required Fund Deposit amount of the Clearing Member or the methodology used to calculate the Required Fund Deposit.</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    Section 17A(b)(3)(F) of the Act requires, in part, that the MBSD Rules be designed to promote the prompt and accurate clearance and settlement of securities transactions.
                    <SU>11</SU>
                    <FTREF/>
                     FICC believes the proposed clarifying and technical changes to the MBSD Rules would allow FICC to help promote prompt and accurate clearance and settlement of securities transactions. This is because the proposed changes to the MBSD Rules would clarify and improve the transparency of the MBSD Rules. Enhancing the clarity and transparency of the MBSD Rules would help Clearing Members to better understand their rights and obligations regarding FICC's clearance and settlement services. FICC believes that when Clearing Members better understand their rights and obligations regarding FICC's clearance and settlement services, they can act in accordance with the MBSD Rules. FICC believes that better enabling Clearing Members to comply with the MBSD Rules would promote the prompt and accurate clearance and settlement of securities transactions by FICC. As such, FICC believes the proposed clarifying and technical changes are consistent with Section 17A(b)(3)(F) of the Act.
                    <SU>12</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         15 U.S.C. 78q-1(b)(3)(F).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD2">(B) Clearing Agency's Statement on Burden on Competition</HD>
                <P>
                    FICC does not believe the proposed rule changes would have any impact on competition. The proposed rule changes would enhance the MBSD Rules by providing additional clarity and transparency, particularly regarding disclosures related to FICC's application of Minimum Charge at MBSD. The proposed rule changes would not advantage or disadvantage any particular Clearing Member of FICC or unfairly inhibit access to FICC's services. FICC therefore does not believe these proposed changes would have any impact, or impose any burden, on competition.
                    <PRTPAGE P="8732"/>
                </P>
                <HD SOURCE="HD2">(C) Clearing Agency's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>FICC has not received or solicited any written comments relating to this proposal. If any additional written comments are received, they will be publicly filed as an Exhibit 2 to this filing, as required by Form 19b-4 and the General Instructions thereto.</P>
                <P>Persons submitting comments are cautioned that, according to Section IV (Solicitation of Comments) of the Exhibit 1A in the General Instructions to Form 19b-4, the Commission does not edit personal identifying information from comment submissions. Commenters should submit only information that they wish to make available publicly, including their name, email address, and any other identifying information.</P>
                <P>
                    All prospective commenters should follow the Commission's instructions on how to submit comments, 
                    <E T="03">available at www.sec.gov/regulatory-actions/how-to-submit-comments.</E>
                     General questions regarding the rule filing process or logistical questions regarding this filing should be directed to the Main Office of the SEC's Division of Trading and Markets at 
                    <E T="03">tradingandmarkets@sec.gov</E>
                     or 202-551-5777.
                </P>
                <P>FICC reserves the right not to respond to any comments received.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change, and Timing for Commission Action</HD>
                <P>
                    The foregoing rule change has become effective pursuant to Section 19(b)(3)(A) 
                    <SU>13</SU>
                    <FTREF/>
                     of the Act and paragraph (f) 
                    <SU>14</SU>
                    <FTREF/>
                     of Rule 19b-4 thereunder. At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act.
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         17 CFR 240.19b-4(f).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>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:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">www.sec.gov/rules/sro.shtml</E>
                    ); or
                </P>
                <P>
                    • Send an email to 
                    <E T="03">rule-comments@sec.gov.</E>
                     Please include File Number  SR-FICC-2024-002 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549.</P>
                <FP>
                    All submissions should refer to File Number SR-FICC-2024-002. This file number should be included on the subject line if email is used. To help the Commission process and review your comments more efficiently, please use only one method. The Commission will post all comments on the Commission's internet website (
                    <E T="03">www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of FICC and on DTCC's website (
                    <E T="03">www.dtcc.com/legal/sec-rule-filings.aspx</E>
                    ). Do not include personal identifiable information in submissions; you should submit only information that you wish to make available publicly. We may redact in part or withhold entirely from publication submitted material that is obscene or subject to copyright protection. All submissions should refer to File Number SR-FICC-2024-002 and should be submitted on or before February 29, 2024.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>15</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             17 CFR 200.30-3(a)(12).
                        </P>
                    </FTNT>
                    <NAME>Sherry R. Haywood,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02520 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <SUBJECT>Meeting of the Interagency Task Force on Veterans Small Business Development</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Small Business Administration (SBA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of open Federal advisory committee meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The SBA is issuing this notice to announce the date, time, and agenda for the next meeting of the Interagency Task Force on Veterans Small Business Development (IATF).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Wednesday, March 6, 2024, from 1 p.m. to 3 p.m. EST.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The meeting will be held virtually via Microsoft Teams.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        The virtual meeting is open to the public; however advance notice of attendance is strongly encouraged. To RSVP and confirm attendance, the general public should email 
                        <E T="03">veteransbusiness@sba.gov</E>
                         with subject line, “RSVP for March 6, 2024, IATF Virtual Public Meeting.” To submit a written comment, individuals should email 
                        <E T="03">veteransbusiness@sba.gov</E>
                         with subject line, “Response for March 6, 2024, IATF Virtual Public Meeting” no later than February 23, 2024, or contact Timothy Green, Acting Associate Administrator, Office of Veterans Business Development (OVBD) at (202) 205-6773. Comments received in advanced will be addressed as time allows during the public comment period. All other submitted comments will be included in the meeting record. During the live meeting, those who wish to comment will be able to do so during the public comment period. Participants can join the meeting via computer at this link: 
                        <E T="03">https://bit.ly/IATF-Mar24</E>
                         or by phone. Call in (audio only): Dial: +1 206-413-7980: Phone Conference ID: 974 812 225#. Special accommodation requests should be directed to OVBD at (202) 205-6773 or 
                        <E T="03">veteransbusiness@sba.gov.</E>
                         All applicable documents will be posted on the IATF website prior to the meeting: 
                        <E T="03">https://www.sba.gov/about-sba/sba-locations/headquarters-offices/office-veterans-business-development#sba-card-collection--heading-7153.</E>
                         For more information on veteran-owned small business programs, please visit 
                        <E T="03">www.sba.gov/ovbd.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Pursuant to section 10(a)(2) of the Federal Advisory Committee Act (5 U.S.C. appendix 2), SBA announces the meeting of the Interagency Task Force on Veterans Small Business Development (IAFT). The IATF is established pursuant to Executive Order 
                    <PRTPAGE P="8733"/>
                    13540 to coordinate the efforts of Federal agencies to improve capital, business development opportunities, and pre-established federal contracting goals for small business concerns owned and controlled by veterans and service-disabled veterans. The purpose of this meeting is to discuss efforts that support veteran-owned small businesses, updates on past and current events, and the IATF's objectives for fiscal year 2024.
                </P>
                <SIG>
                    <DATED>Dated: January 30, 2024.</DATED>
                    <NAME>Andrienne Johnson,</NAME>
                    <TITLE>Committee Manager Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02597 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20162 and #20163; NORTH CAROLINA Disaster Number NC-20001]</DEPDOC>
                <SUBJECT>Administrative Declaration of a Disaster for the State of North Carolina</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a notice of an Administrative declaration of a disaster for the State of North Carolina dated 02/01/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Tornado.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         01/09/2024.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 02/01/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         11/01/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Vanessa Morgan, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the Administrator's disaster declaration, applications for disaster loans may be submitted online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties:</E>
                     Catawba.
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Contiguous Counties:</E>
                </FP>
                <FP SOURCE="FP1-2">North Carolina: Alexander, Burke, Caldwell, Iredell, and Lincoln.</FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners with Credit Available Elsewhere</ENT>
                        <ENT>5.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners without Credit Available Elsewhere</ENT>
                        <ENT>2.688</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses with Credit Available Elsewhere</ENT>
                        <ENT>8.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Business and Small Agricultural Cooperatives without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 20162C and for economic injury is 201630.</P>
                <P>The State which received an EIDL Declaration is North Carolina.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Isabella Guzman,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02547 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20183 and #20184; TENNESSEE Disaster Number TN-20010]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for Public Assistance Only for the State of Tennessee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for Public Assistance Only for the State of Tennessee (FEMA-4751-DR), dated 01/30/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Tornadoes.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         12/09/2023.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 01/30/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         10/30/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Alan Escobar, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 01/30/2024, Private Non-Profit organizations that provide essential services of a governmental nature may file disaster loan applications online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties:</E>
                     Cheatham, Davidson, Dickson, Gibson, Montgomery, Robertson, Stewart, Sumner, Weakley.
                </FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 20183C and for economic injury is 201840.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Francisco Sánchez, Jr.,</NAME>
                    <TITLE>Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02564 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20181 and #20182; NEW YORK Disaster Number NY-20007]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for Public Assistance Only for the State of New York</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for Public Assistance Only for the State of New York (FEMA-4755-DR), dated 01/30/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Flooding.
                        <PRTPAGE P="8734"/>
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         09/28/2023 through 09/30/2023.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 01/30/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         10/31/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Vanessa Morgan, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 01/30/2024, Private Non-Profit organizations that provide essential services of a governmental nature may file disaster loan applications online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-1">
                    <E T="03">Primary Counties:</E>
                     Kings, Nassau, Westchester.
                </FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 201816 and for economic injury is 201820.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Francisco Sánchez, Jr.,</NAME>
                    <TITLE>Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02546 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20148 and #20149; MAINE Disaster Number ME-20001]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for the State of Maine</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for the State of Maine (FEMA-4754-DR), dated 01/30/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Flooding.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         12/17/2023 through 12/21/2023.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 01/30/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         10/30/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Alan Escobar, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 01/30/2024, applications for disaster loans may be submitted online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties (Physical Damage and Economic Injury Loans):</E>
                     Androscoggin, Franklin, Kennebec, Oxford, Somerset.
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Contiguous Counties (Economic Injury Loans Only):</E>
                </FP>
                <FP SOURCE="FP1-2">Maine: Aroostook, Cumberland, Lincoln, Penobscot, Piscataquis, Sagadahoc, Waldo, York.</FP>
                <FP SOURCE="FP1-2">New Hampshire: Carroll, Coos.</FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners with Credit Available Elsewhere</ENT>
                        <ENT>5.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners without Credit Available Elsewhere</ENT>
                        <ENT>2.688</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses with Credit Available Elsewhere</ENT>
                        <ENT>8.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Business and Small Agricultural Cooperatives without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 201486 and for economic injury is 201490.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Francisco Sánchez, Jr.,</NAME>
                    <TITLE>Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02561 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20179 and #20180; WEST VIRGINIA Disaster Number WV-20001]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for the State of West Virginia</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for the State of West Virginia (FEMA-4756-DR), dated 01/30/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms, Flooding, Landslides, and Mudslides.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         08/28/2023 through 08/30/2023.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 01/30/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         10/30/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Alan Escobar, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 01/30/2024, applications for disaster loans may be submitted online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service 
                    <PRTPAGE P="8735"/>
                    center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties (Physical Damage and Economic Injury Loans):</E>
                     Boone, Calhoun, Clay, Harrison, Kanawha.
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Contiguous Counties (Economic Injury Loans Only):</E>
                </FP>
                <FP SOURCE="FP1-2">West Virginia: Barbour, Braxton, Doddridge, Fayette, Gilmer, Jackson, Lewis, Lincoln, Logan, Marion, Nicholas, Putnam, Raleigh, Ritchie, Roane, Taylor, Upshur, Wetzel, Wirt, Wyoming.</FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s25,9">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners with Credit Available Elsewhere</ENT>
                        <ENT>5.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners without Credit Available Elsewhere</ENT>
                        <ENT>2.500</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses with Credit Available Elsewhere</ENT>
                        <ENT>8.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Business and Small Agricultural Cooperatives without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>2.375</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 201796 and for economic injury is 201800.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Francisco Sánchez, Jr.,</NAME>
                    <TITLE>Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02548 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20185 and #20186; MAINE Disaster Number ME-20004]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for Public Assistance Only for the State of Maine</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for Public Assistance Only for the State of Maine (FEMA-4754-DR), dated 01/30/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Flooding.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         12/17/2023 through 12/21/2023.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 01/30/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         04/01/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         10/30/2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Alan Escobar, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 01/30/2024, Private Non-Profit organizations that provide essential services of a governmental nature may file disaster loan applications online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties:</E>
                     Androscoggin, Franklin, Hancock, Oxford, Penobscot, Piscataquis, Somerset, Waldo, Washington.
                </FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 201856 and for economic injury is 201860.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Francisco Sánchez, Jr.,</NAME>
                    <TITLE>Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02560 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <SUBJECT>Meeting of the Advisory Committee on Veterans Business Affairs</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Small Business Administration (SBA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of open Federal advisory committee meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The SBA is issuing this notice to announce the date, time, and agenda for a meeting of the Advisory Committee on Veterans Business Affairs (ACVBA).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Thursday, March 7, 2024, from 9 a.m. to 3 p.m. EST.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The meeting will be held virtually via Microsoft Teams.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        The virtual meeting is open to the public; however advance notice of attendance is strongly encouraged. To RSVP and confirm attendance, the general public should email 
                        <E T="03">veteransbusiness@sba.gov</E>
                         with subject line, “RSVP for March 7, 2024, ACVBA Virtual Public Meeting.” To submit a written comment, individuals should email 
                        <E T="03">veteransbusiness@sba.gov</E>
                         with subject line, “Response for March 7, 2024, ACVBA Virtual Public Meeting” no later than February 23, 2024, or contact Timothy Green, Acting Associate Administrator, Office of Veterans Business Development (OVBD) at (202) 205-6773. Comments received in advanced will be addressed as time allows during the public comment period. All other submitted comments will be included in the meeting record. During the live meeting, those who wish to comment will be able to do so during the public comment period.
                    </P>
                    <P>
                        Participants can join the meeting via computer at this link: 
                        <E T="03">https://bit.ly/ACVBA-Mar24</E>
                         or by phone. Call in (audio only): Dial: +1 206-413-7980: Phone Conference 889 719 784# Special accommodation requests should be directed to OVBD at (202) 205-6773 or 
                        <E T="03">veteransbusiness@sba.gov.</E>
                         All applicable documents will be posted on the ACVBA website prior to the meeting: 
                        <E T="03">https://www.sba.gov/about-sba/sba-locations/headquarters-offices/office-veterans-business-development#sba-card-collection--heading-7153.</E>
                         For more information on veteran-owned small business programs, please visit 
                        <E T="03">www.sba.gov/ovbd.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Pursuant to section 10(a)(2) of the Federal Advisory Committee Act (5 U.S.C. appendix 2), SBA announces the meeting of the Advisory Committee on Veterans Business Affairs. The ACVBA is established pursuant to 15 U.S.C. 657(b) note and serves as an 
                    <PRTPAGE P="8736"/>
                    independent source of advice and policy. The purpose of this meeting is to discuss efforts that support veteran-owned small businesses, updates on past and current events, and the ACVBA's objectives for fiscal year 2024.
                </P>
                <SIG>
                    <DATED>Dated: January 30, 2024.</DATED>
                    <NAME>Andrienne Johnson,</NAME>
                    <TITLE>Committee Manager Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02599 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF STATE</AGENCY>
                <DEPDOC>[Public Notice: 12322]</DEPDOC>
                <SUBJECT>International Security Advisory Board (ISAB) Meeting Notice</SUBJECT>
                <HD SOURCE="HD1">Closed Meeting</HD>
                <P>In accordance with section 10(a)(2) of the Federal Advisory Committee Act, 5 U.S.C. 1009(a)(2), the Department of State announces a meeting of the International Security Advisory Board (ISAB) to take place on March 12, 2024, at the Department of State, Washington, DC.</P>
                <P>Pursuant to section 10(d) of the Federal Advisory Committee Act, 5 U.S.C. 1009(d), and 5 U.S.C. 552b(c)(1), it has been determined that this Board meeting will be closed to the public because the Board will be reviewing and discussing matters properly classified in accordance with Executive Order 13526. The purpose of the ISAB is to provide the Department with a continuing source of independent advice on all aspects of arms control, disarmament, nonproliferation, outer space, critical infrastructure, cybersecurity, the national security aspects of associated technologies, international security, and related aspects of public diplomacy. The agenda for this meeting will include classified discussions related to the Board's ongoing studies on current U.S. policy and issues regarding arms control, international security, nuclear proliferation, associated technologies, climate and energy security.</P>
                <P>For more information, contact Michelle Dover, Executive Director of the International Security Advisory Board, Department of State, Washington, DC 20520, telephone: (202) 736-4930.</P>
                <SIG>
                    <NAME>Michelle Dover,</NAME>
                    <TITLE>Executive Director, International Security Advisory Board, Department of State.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-02606 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4710-27-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Highway Administration</SUBAGY>
                <DEPDOC>[Docket No. FHWA-2024-0009]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities: Notice of Request for Renewal of Currently Approved Information Collection</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Highway Administration (FHWA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for extension of currently approved information collection.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The FHWA has forwarded the information collection request described in this notice to the Office of Management and Budget (OMB) for approval of a renewal of information collection. We published a 
                        <E T="04">Federal Register</E>
                         Notice with a 60-day public comment period on this information collection on October 31, 2023. We are required to publish this notice in the 
                        <E T="04">Federal Register</E>
                         by the Paperwork Reduction Act of 1995.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Please submit comments by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments identified by DOT Docket ID Number 0009 by any of the following methods:</P>
                    <P>
                        <E T="03">Website:</E>
                         For access to the docket to read background documents or comments received go to the Federal eRulemaking Portal: Go to 
                        <E T="03">http://www.regulations.gov</E>
                        . Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Fax:</E>
                         1-202-493-2251.
                    </P>
                    <P>
                        <E T="03">Mail:</E>
                         Docket Management Facility, U.S. Department of Transportation, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590-0001.
                    </P>
                    <P>
                        <E T="03">Hand Delivery or Courier:</E>
                         U.S. Department of Transportation, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590, between 9 a.m. and 5 p.m. ET, Monday through Friday, except Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Mr. Omar Elkassed, (213) 894-6718, Office of Stewardship, Oversight, and Program Management, Federal Highway Administration, Department of Transportation, 888 South Figueroa Street, Suite 440, Los Angeles, CA 90017. Office hours are from 7 a.m. to 4 p.m., Monday through Friday, except Federal holidays.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The comments and FHWA's responses to the 60-day notice published October 31, 2023 at 88 FR 74557 are below:</P>
                <FP SOURCE="FP-1">• Virginia Department of Transportation (VDOT)</FP>
                <P>○ Whether the proposed collection is necessary for the FHWA 's performance:</P>
                <P> The Fiscal Management Information System (FMIS), which generates the project agreement, contains a PREFIX Field, which is established at the onset of a project on the state's allocation. As estimates are updated, multiple fund sources can be added to a project at the state's discretion; however, the PREFIX field is not required to be revised as additional federal funding sources are added. VDOT therefore recommends that the PREFIX Field be removed from FMIS, as it does not appear to serve any purpose from the state's perspective.</P>
                <P>
                      
                    <E T="03">Response:</E>
                     The prefix field on the project detail screen is an optional field and will not prevent you from obligating funds.
                </P>
                <P>○ The accuracy of the estimated burdens:</P>
                <P> Based on the complexity and the phase of project data required, Virginia averages an estimated 1.0 to 1.5 how-s to complete a project agreement.</P>
                <P>
                      
                    <E T="03">Response:</E>
                     Thank you for your input on the estimated duration to complete a project agreement in Virginia. The estimated burdens hours in the notice is based on nationwide average.
                </P>
                <P>○ Ways for the FHWA to enhance the quality, usefulness and clarity of the collected information.</P>
                <P> VDOT recommends that FHWA develop additional standard reports for states to utilize on data fields in FMIS for analysis of data as needed. That would save time so that states would not have to create reports on their own using the Business Objects tool within FMIS. Additionally, it would ensure that all states are consistently reporting data from the same source in response to FHWA requests.</P>
                <P>
                      
                    <E T="03">Response:</E>
                     FMIS has a set of standard reports in the Reports module in FMIS and a set of Resource Center and developer created reports in Business Objects under the following Public Folders: BUGS University—Help, Delphi Reporting Tool (DRT), and FMIS5. If your state would like assistance to develop specific reports for your state, you may reach out to the FDAT for assistance.
                </P>
                <P>○ Ways that the burden could be minimized, including the use of electronic technology, without reducing the quality of the collected information</P>
                <P> VDOT recommends that FHWA provide clearer communication to states when/if FHWA updates FMIS in order to allow states sufficient time to update their IT requirements/recode data for FHWA's Electronic Data System (EDS).</P>
                <P>
                      
                    <E T="03">Response:</E>
                     In September 2023, we extended the FMIS system change notification period to states from 60-
                    <PRTPAGE P="8737"/>
                    days to 90-days. Recipients receive notification from their Division Office of these changes and are notified on the FMIS opening page message board after sign in.
                </P>
                <P>• California Department of Transportation</P>
                <P>○ Caltrans recommends that state requests for agreement modifications resulting in net-zero obligation be allowed when the unobligated apportionment balance is less than the obligation amount of the request, without considering the de-obligation portion.</P>
                <P>
                    ○ 
                    <E T="03">Response:</E>
                     The Fiscal Management Information System (FMIS) must validate funding availability in FMIS and Delphi. In the instance of a de-obligation when unobligated apportionment balance is zero or less than the obligation request, FMIS indicates an over-obligation error until the de-obligation is posted to Delphi. Once posted to Delphi, new obligations may occur up to the unobligated balance.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Preparation and Execution of the Project Agreement and Modifications.
                </P>
                <P>
                    <E T="03">OMB Control #:</E>
                     2125-0529.
                </P>
                <P>
                    <E T="03">Background:</E>
                     Formal agreements between State Transportation Departments and the FHWA are required for Federal-aid highway projects. These agreements, referred to as “project agreements” are written contracts between the State and the Federal government that define the extent of work to be undertaken and commitments made concerning a highway project. Section 1305 of the Transportation Equity Act for the 21st Century (TEA-21, Pub. L. 105-178) amended 23 U.S.C. 106(a) and combined authorization of work and execution of the project agreement for a Federal-aid project into a single action. States continue to have the flexibility to use whatever format is suitable to provide the statutory information required, and burden estimates for this information collection are not changed.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     There are 56 respondents, including 50 State Transportation Departments, the District of Columbia, the Commonwealth of Puerto Rico, the Commonwealth of the Northern Mariana Islands, Guam, the Virgin Islands and American Samoa. Depending on the size of and activity in the above government agencies, the number of project agreements executed in any agency ranges between 10 and 1,500.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On an on-going basis as project agreements are written.
                </P>
                <P>
                    <E T="03">Estimated Average Burden per Response:</E>
                     There is a total of 23,809 agreements per year. Each agreement requires 1 hour to complete.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     Total estimated average annual burden is 23,809 hours.
                </P>
                <P>
                    <E T="03">Public Comments Invited:</E>
                     You are asked to comment on any aspect of this information collection, including: (1) Whether the proposed collection is necessary for the FHWA's performance; (2) the accuracy of the estimated burdens; (3) ways for the FHWA to enhance the quality, usefulness, and clarity of the collected information; and (4) ways that the burden could be minimized, including the use of electronic technology, without reducing the quality of the collected information. The agency will summarize and/or include your comments in the request for OMB's clearance of this information collection.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     The Paperwork Reduction Act of 1995; 44 U.S.C. chapter 35, as amended; and 49 CFR 1.48.
                </P>
                <SIG>
                    <DATED> Issued On: February 5, 2024.</DATED>
                    <NAME>Jazmyne Lewis,</NAME>
                    <TITLE>Information Collection Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02572 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Motor Carrier Safety Administration</SUBAGY>
                <DEPDOC>[Docket No. FMCSA-2024-0061]</DEPDOC>
                <SUBJECT>Request for Information Concerning the Study of Sexual Assault and Sexual Harassment in the Commercial Motor Vehicle Industry</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Motor Carrier Safety Administration (FMCSA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; request for information.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>FMCSA is planning to undertake a study to understand and quantify the prevalence and severity of sexual assault and sexual harassment (SASH) experienced across the commercial motor vehicle (CMV) industry, particularly among drivers. FMCSA seeks information on how best to design and conduct a study to identify, categorize, and assess context and trends of SASH in the CMV industry. FMCSA is particularly interested in how to support women currently in these jobs and those seeking to enter the CMV industry. This RFI seeks information on how best to approach this study holistically in terms of statistical sampling, study design, and administering the appropriate data collection efforts. For example, FMCSA seeks information on how best to treat categories of gender, sexual orientation, and ethnicity in the study, as well as best practices in designing questions that use the latest standards for SASH research and address the breadth and lifecycles of careers in the CMV industry. This study builds on recommendations from FMCSA's Women of Trucking Advisory Board (WOTAB) to better understand problems of SASH among drivers, thereby helping identify possible countermeasures. FMCSA will use the results of this study to understand any potential regulatory or policy measures needed to improve driver safety and mitigate SASH; work with industry partners on outreach and other efforts to improve driver safety through SASH prevention; and support the participation of women in the CMV industry.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on this notice must be received on or before March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments identified by Docket Number FMCSA-2024-0061 using any of the following methods:</P>
                    <P>
                        • Go to 
                        <E T="03">https://www.regulations.gov/docket/FMCSA-2024-0061/document.</E>
                         Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Dockets Operations, U.S. Department of Transportation, 1200 New Jersey Avenue SE, West Building, Ground Floor, Washington, DC 20590-0001.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         Dockets Operations, U.S. Department of Transportation, 1200 New Jersey Avenue SE, West Building, Ground Floor, Washington, DC 20590-0001, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. To be sure someone is there to help you, please call (202) 366-9317 or (202) 366-9826 before visiting Dockets Operations.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (202) 493-2251.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Nicole Katsikides, Ph.D., Senior Transportation Specialist, Research Division, FMCSA, 1200 New Jersey Avenue SE, Washington, DC 20590-0001; (202) 940-6645; 
                        <E T="03">Nicole.Katsikides@dot.gov.</E>
                         If you have questions on viewing or submitting material to the docket, contact Dockets Operations at (202) 366-9826.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>FMCSA organizes this notice as follows:</P>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Public Participation and Request for Comments</FP>
                    <FP SOURCE="FP1-2">A. Submitting Comments</FP>
                    <FP SOURCE="FP1-2">B. Viewing Comments and Documents</FP>
                    <FP SOURCE="FP1-2">C. Privacy Act</FP>
                    <FP SOURCE="FP1-2">
                        D. Comments on the Information Collection
                        <PRTPAGE P="8738"/>
                    </FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">III. Request for Information</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Public Participation and Request for Comments</HD>
                <P>FMCSA encourages you to participate by submitting comments and related materials.</P>
                <HD SOURCE="HD2">A. Submitting Comments</HD>
                <P>If you submit a comment, please include the docket number for this notice (FMCSA-2024-0061), indicate the specific section of this document to which your 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 FMCSA can contact you if there are questions regarding your submission.</P>
                <P>
                    To submit your comment online, go to 
                    <E T="03">https://www.regulations.gov/docket/FMCSA-2024-0061/document,</E>
                     click on this notice, click “Comment,” and type your comment into the text box on the following screen.
                </P>
                <P>
                    If you submit your comments by mail or hand delivery, submit them in an unbound format, no larger than 8
                    <FR>1/2</FR>
                     by 11 inches, suitable for copying and electronic filing.
                </P>
                <P>FMCSA will consider all comments and material received during the comment period.</P>
                <HD SOURCE="HD3">Confidential Business Information (CBI)</HD>
                <P>
                    CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to the notice contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to the notice, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission that constitutes CBI as “PROPIN” to indicate it contains proprietary information. FMCSA will treat such marked submissions as confidential under the Freedom of Information Act, and they will not be placed in the public docket of the Notice. Submissions containing CBI should be sent to Brian Dahlin, Chief, Regulatory Evaluation Division, Office of Policy, FMCSA, 1200 New Jersey Avenue SE, Washington DC 20590-0001 or via email at 
                    <E T="03">brian.g.dahlin@dot.gov.</E>
                     At this time, you need not send a duplicate hardcopy of your electronic CBI submissions to FMCSA headquarters. Any comments FMCSA receives not specifically designated as CBI will be placed in the public docket for this notice.
                </P>
                <HD SOURCE="HD2">B. Viewing Comments and Documents</HD>
                <P>
                    To view any documents mentioned as being available in the docket, go to 
                    <E T="03">https://www.regulations.gov/docket/FMCSA-2024-0061/document</E>
                     and choose the document to review. To view comments, click this notice, then click “Browse Comments.” If you do not have access to the internet, you may view the docket online by visiting Dockets Operations on the ground floor of the DOT West Building, 1200 New Jersey Avenue SE, Washington, DC 20590-0001, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. To be sure someone is there to help you, please call (202) 366-9317 or (202) 366-9826 before visiting Dockets Operations.
                </P>
                <HD SOURCE="HD2">C. Privacy Act</HD>
                <P>
                    In accordance with 5 U.S.C. 553(c), DOT solicits comments from the public to better inform its regulatory process. DOT posts these comments, including any personal information the commenter provides, to 
                    <E T="03">www.regulations.gov</E>
                     as described in the system of records notice DOT/ALL 14 (Federal Docket Management System (FDMS)), which can be reviewed at 
                    <E T="03">https://www.transportation.gov/individuals/privacy/privacy-act-system-records-notices.</E>
                     The comments are posted without edit and are searchable by the name of the submitter.
                </P>
                <HD SOURCE="HD1">II. Background</HD>
                <P>
                    SASH are long-standing challenges for the CMV driving community, particularly for women. Addressing these challenges is a priority for the Department, FMCSA, and WOTAB.
                    <E T="51">1 2</E>
                    <FTREF/>
                     Through previous research efforts, FMCSA sought to understand, characterize, and assess the prevalence and severity of SASH within the CMV industry. FMCSA had little information on the breadth of SASH problems in the industry or recommendations for solutions, and a study, 
                    <E T="03">Crime Prevention for Truckers Study,</E>
                     helped frame the issues, including how to best support women in CMV careers through countermeasures designed to mitigate SASH.
                    <SU>3</SU>
                    <FTREF/>
                     Further, this study evaluated harassment of women and minority men truckers with incidents among non-minority men serving as a control group.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Chartered by the Secretary of Transportation on February 11, 2022, WOTAB is charged with reviewing and reporting on policies that provide education, training, mentorship, or outreach to women in the trucking industry and to improve recruitment, retention, or advancement of women in the trucking industry (
                        <E T="03">https://www.fmcsa.dot.gov/wotab</E>
                        ).
                    </P>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">https://www.fmcsa.dot.gov/advisory-committees/wotab/wotab-meetings.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">https://www.fmcsa.dot.gov/research-and-analysis/crime-prevention-truckers-study.</E>
                    </P>
                </FTNT>
                <P>The study found that harassment and crime against drivers are prevalent. Drivers reported a range of harassment types, such as being called offensive names or threatened with weapons. Further, harassment is not limited by gender and race, as the study found it extends to religion, lifestyle, and sexual orientation. The study concluded that women truck drivers are particularly vulnerable to crimes that are sexual in nature and are more likely to experience harassment from another truck driver or from trainers. Crimes against women truck drivers are more likely to happen at night, though they also occur throughout the day and cycle of a driver's run.</P>
                <P>The study further found that many harassment incidents go unreported, but women are reporting more than men. Most respondents said that they did not think reporting harassment would make a difference. Many felt there might be retaliation or problems in some way, and they chose not to report the incident(s). However, women truck drivers were found to be two to four times more likely to report being touched without permission compared to non-minority men, and minority women were up to nine times more likely to report being physically harmed compared to non-minority men. Non-minority women are two to six times as likely than non-minority men to be touched without permission. The study included recommendations that were taken from the survey respondents' comments (although these recommendations were not evaluated to determine feasibility, appropriateness, and most importantly, their ability to improve driver safety).</P>
                <P>
                    When the study was released, WOTAB received several comments, formally and informally, from industry groups and organizations focused on researching and stopping violence against women and SASH.
                    <E T="51">4 5 6</E>
                    <FTREF/>
                     These organizations expressed concern that 
                    <PRTPAGE P="8739"/>
                    the FMCSA study was not comprehensive and that more questions needed to be asked to determine the full nature of the SASH problem. Key areas of concern included:
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">https://www.fmcsa.dot.gov/mission/advisory-committees/wotab/national-womens-law-center-public-comment.</E>
                    </P>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">https://www.fmcsa.dot.gov/mission/advisory-committees/wotab/futures-without-violence-public-comment.</E>
                    </P>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">https://www.fmcsa.dot.gov/mission/advisory-committees/wotab/real-women-trucking-public-comment-solutions-address-sexual.</E>
                    </P>
                </FTNT>
                <P>1. Sample design and categories of gender, sexual orientation, and ethnicity.</P>
                <P>2. Types of questions asked to capture SASH and not using the latest standards in SASH research to design questions.</P>
                <P>3. Development of appropriate and evaluated recommendations to inform actions for SASH prevention.</P>
                <P>While the study framed the SASH issues in the industry and provided some preliminary data to understand magnitude, WOTAB's discussions on the study and other issues for women in the CMV industry indicated a need for additional research, especially to support improved participation of women in CMV careers. Additional research was suggested to support potential policy changes that would address improvements to current practices and reporting methods for drivers related to SASH, and to establish improved outreach and safety resources. WOTAB noted in particular that it is important to understand SASH with additional depth and breadth to ensure there is an awareness of the magnitude of SASH across the industry.</P>
                <P>Therefore, FMCSA seeks to develop a comprehensive, expanded study that achieves a deeper framing and understanding of baseline data and issues related to SASH. FMCSA seeks input from stakeholders to help in the design of a new study.</P>
                <HD SOURCE="HD1">III. Request for Information</HD>
                <P>In developing the SASH study, FMCSA seeks input on the elements that should be included or considered. Please include answers to the following questions in your response:</P>
                <P>1. What is the optimal study design to capture SASH information within the CMV industry, particularly among drivers? FMCSA is considering a survey and interview approach, as well as potential peer reviews of findings at key milestones throughout the study. What type of study design will best characterize the nature and scope of sexual assault and sexual harassment within the CMV industry that can be used to develop appropriate countermeasures?</P>
                <P>2. What are best practices or methods for capturing gender identity information?</P>
                <P>3. What are best practices to consider when asking demographic questions about sexual orientation and ethnicity?</P>
                <P>
                    4. Are there other categories of participant demographics that would improve the study (
                    <E T="03">e.g.,</E>
                     education, age, income, length of time in position (or in the industry), segment of the CMV industry, geographic region of operation, etc.)? Please be specific and provide rationale for including such questions, including how they may be used in characterizing the SASH problem and developing countermeasures and recommendations.
                </P>
                <P>
                    5. Who should be included (
                    <E T="03">i.e.,</E>
                     targeted stakeholders) in a SASH study for the CMV industry?
                </P>
                <P>
                    6. What options exist to best incorporate stakeholder input and feedback throughout the study (
                    <E T="03">e.g.,</E>
                     surveys, individual interviews, focus groups, or other formats)?
                </P>
                <P>
                    7. What research is available for designing and administering questions about SASH (
                    <E T="03">e.g.,</E>
                     style of questions, sequencing, repetition, phrasing, etc.)?
                </P>
                <P>
                    8. What are the best methods to capture SASH issues and trends throughout the evolution of one's career (trainee, driver, other positions across the CMV industry (
                    <E T="03">e.g.,</E>
                     manager, trainer, scheduler, safety employee, retiree, those who have left the industry)?
                </P>
                <P>9. What are the optimum methods to capture the breadth of SASH? What categories of questions should FMCSA include that will ensure a comprehensive approach to the issue?</P>
                <P>
                    10. What are good practices for informing stakeholders and the public at key milestones during a long study? How can FMCSA best disseminate information (
                    <E T="03">e.g.,</E>
                     literature review, preliminary results) to keep stakeholders informed without compromising the integrity of the study?
                </P>
                <SIG>
                    <P>Issued under authority delegated in 49 CFR 1.87.</P>
                    <NAME>Sue Lawless,</NAME>
                    <TITLE>Acting Deputy Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02539 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-EX-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Emergency Order No. 33, Notice No.1]</DEPDOC>
                <SUBJECT>Emergency Order To Prevent Operation of Trains and Other On-Track Rail Equipment on Blackwell Northern Gateway Railroad</SUBJECT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Federal Railroad Administration (FRA) of the United States Department of Transportation has determined that public safety compels the issuance of an Emergency Order (Order) requiring the Blackwell Northern Gateway Railroad (BNGR) of Blackwell, Oklahoma, to discontinue operation of all trains, locomotives, and any other on-track rail vehicles or equipment under any circumstances over any track BNGR leases or owns, including the rail line extending from milepost (MP) 0.09 at Wellington, Kansas, to MP 35.35 at Blackwell, Oklahoma, and from MP 127.0 to MP 125.0 at Blackwell until BNGR complies with all requirements of this Order.</P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Christian Holt, Staff Director, Operating Practices Division, Office of Railroad Safety at (202) 366-0978 or 
                        <E T="03">Christian.Holt@dot.gov;</E>
                         Elliott Gillooly, Attorney Adviser, Office of the Chief Counsel, at (202) 897-8666 or 
                        <E T="03">Elliott.Gillooly@dot.gov;</E>
                         or Veronica Chittim, Attorney Adviser, Office of the Chief Counsel, at (202) 480-3410 or 
                        <E T="03">Veronica.Chittim@dot.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Introduction</HD>
                <P>As provided below, FRA has determined that public safety compels the issuance of this Order requiring BNGR to discontinue operations of all trains, locomotives, or any other on-track rail vehicles or equipment under any circumstances over any track it leases or owns, including the rail line extending from MP 0.09 at Wellington, Kansas, to MP 35.35 at Blackwell, Oklahoma, and from MP 127.0 to MP 125.0 at Blackwell until BNGR complies with all requirements of this Order.</P>
                <HD SOURCE="HD1">Authority</HD>
                <P>
                    Authority to enforce Federal railroad safety laws has been delegated by the U.S. Secretary of Transportation (Secretary) to the Administrator of FRA. 49 U.S.C. 103; 49 CFR 1.89(e). Railroads are subject to FRA's safety jurisdiction under the Federal railroad safety laws. 49 U.S.C. 20101, 20103. FRA is authorized to issue emergency orders where “an unsafe condition or practice, or a combination of unsafe conditions and practices, causes an emergency situation involving a hazard of death, personal injury, or significant harm to the environment.” 49 U.S.C. 20104. Emergency orders may immediately impose “restrictions and prohibitions . . . that may be necessary to abate the situation.” 
                    <E T="03">Id.</E>
                </P>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    BNGR operates on approximately 37 miles of rail line owned by the Oklahoma Department of Transportation (ODOT) and the Blackwell Industrial Authority (BIA). The line extends from Blackwell, Oklahoma, to Wellington, Kansas, where BNGR interchanges with 
                    <PRTPAGE P="8740"/>
                    BNSF Railway. All track on the BNGR line is designated as “excepted” track, meaning that trains are limited to speeds of 10 miles per hour. BNGR operations on all track is further designated as “yard limits,” meaning that crews must be prepared to stop within one half the range of vision at all times when moving trains and engines. BNGR ownership changed on or about October 1, 2023. FRA is aware of several serious incidents that have occurred following the change in BNGR ownership, including two derailments and a highly dangerous movement of on-track equipment through an unprotected highway-rail grade crossing, narrowly missing a collision with a passenger vehicle.
                </P>
                <P>FRA recently began investigating BNGR's operations following a derailment that occurred on December 27, 2023. FRA has found that BNGR is operating with a complete disregard for the safety of the public and has not taken corrective action to resolve safety issues identified by FRA as posing imminent risks of injury or death. BNGR has, in its short time under current ownership, operated locomotives not safe for use under Federal law (49 U.S.C. 20701, 49 CFR part 229), allowed locomotives to be operated by persons not properly qualified as engineers in accordance with FRA regulations (49 CFR part 240), and failed to qualify any engineers or conductors under any qualification program in accordance with FRA regulations (49 CFR parts 240 and 242, respectively). BNGR has maintained no records of track safety inspections, no records of employees designated and qualified to perform track inspections, and no records that roadway workers have been trained to use roadway maintenance machines or perform safety-essential functions in accordance with FRA regulations (49 CFR parts 213 and 214).</P>
                <P>
                    Further, in violation of FRA regulations (49 CFR part 225), BNGR has failed to report, at a minimum, the two derailments that FRA has discovered through its investigation. In both derailments, the individual operating the derailed train was not properly qualified as an engineer in accordance with 49 CFR part 240, including at least one instance when the train's locomotive was also several years past its required periodic inspection (
                    <E T="03">see</E>
                     49 CFR 229.23(a)). Additionally, there is evidence that persons not employed by the railroad and with no qualification under FRA regulations were allowed to operate locomotives (
                    <E T="03">see</E>
                     49 CFR 240.201(d)). Moreover, there is evidence BNGR employees have been directed by BNGR ownership to provide FRA false information, including a false engineer certification card and false hours of service (HOS) records.
                </P>
                <P>BNGR has created a public safety emergency through a willful failure to undertake basic responsibilities such as track inspection and training for safety-related railroad employees in combination with the deliberate actions of one or more individuals in positions of authority at this railroad. FRA has obtained substantial evidence that the most senior person on location at the BNGR, a co-owner of the railroad, has personally operated locomotives and trains on the BNGR line without the required training or qualification, leading to derailments, and has provided false information to FRA. Evidence also shows this individual has directed employees to act in ways that are unsafe and wholly contrary to a safety culture railroad employees expect and require to do their jobs properly, including directions to put locomotives into service not fit for use and prepare false HOS records. Aggravating all of the foregoing concerns, BNGR has not provided FRA with documentation that the railroad has a written program of operational tests and inspections on its operating rules in accordance with FRA regulations (49 CFR 217.9) or the required training program for its safety-related employees under 49 CFR part 243.</P>
                <P>
                    On January 17, 2024, FRA found no program for track inspection in compliance with FRA safety regulations (49 CFR part 213) and no inspection records for any month from the time the BNGR came under current ownership (October through December 2023). Following these findings, BNGR's manager represented to FRA that all track over which BNGR operates would be taken out of service. Under 49 CFR part 213, any movements on track that is out of service for repairs must be authorized by a § 213.7 qualified person and be made only to facilitate repairs. 
                    <E T="03">See</E>
                     § 213.233(d).
                </P>
                <P>
                    On Sunday, January 28, 2024, witnesses reported that at approximately 5:15 p.m., C.S.T., an on-track hi-rail vehicle 
                    <SU>1</SU>
                    <FTREF/>
                     nearly collided with a highway passenger vehicle at a highway-rail grade crossing at Doolin Avenue over the BNGR line near Blackwell, Oklahoma. This incident demonstrates a cascade of failures to protect life and safety by BNGR, as the grade crossing signal system at the highway-rail grade crossing was not activated, no flag protection of the intersection was provided, and the hi-rail vehicle reportedly made no effort to stop and yield the right-of-way to vehicular traffic at the crossing, which is a customary railroad safety practice and often part of a railroad's operating rules under 49 CFR part 217.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         A hi-rail vehicle is a roadway maintenance machine that is manufactured to meet Federal Motor Vehicle Safety Standards and is equipped with retractable flanged wheels so that the vehicle may travel over the highway or on railroad tracks. 
                        <E T="03">See</E>
                         49 CFR 214.5.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Finding and Order</HD>
                <P>The evidence developed in FRA's investigation of the BNGR has led FRA to conclude that continued operation of any rail equipment by BNGR on any part of its line poses an imminent threat to safety, including the threat of serious harm to persons employed by BNGR and the public. Further, the pattern of gross negligence and willful failures to comply with Federal safety regulations in multiple functional areas, including track safety, locomotive engineer qualification and certification, operating practices, and roadway worker safety, persuades FRA that reliance alone upon the assurances and cooperation of BNGR is not possible, consistent with public safety. Therefore, as the Administrator of FRA, I find that the combination of unsafe conditions and practices discussed above creates an emergency situation involving a hazard of death or injury to persons.</P>
                <P>Accordingly, pursuant to the authority of 49 U.S.C. 20104, delegated to me by the Secretary, it is ordered that BNGR must discontinue, and may not permit under any circumstances, the operations of trains, locomotives, or any other on-track rail vehicles or equipment on any part of the track that it owns or leases from ODOT or the BIA, including all track between Wellington, Kansas, and Blackwell, Oklahoma, while this Order remains in effect. I direct that a copy of this Order be posted in a public location at the railroad's office and a copy of the Order be provided to each employee of the railroad within 24 hours of the date of issuance.</P>
                <P>FRA investigation of this railroad is ongoing, and FRA may take further steps to assure public safety. These steps may include additional notice(s) under this Order and/or other enforcement action.</P>
                <HD SOURCE="HD1">Relief</HD>
                <P>BNGR may only resume operations and obtain full relief from this Order by taking the following actions:</P>
                <P>
                    1. Submit to FRA for approval both a current, written program for certifying the qualification of engineers under 49 CFR part 240 and a current, written program for certifying the qualification 
                    <PRTPAGE P="8741"/>
                    of conductors under 49 CFR part 242. 
                    <E T="03">See</E>
                     49 CFR 240.101; 49 CFR 242.101.
                </P>
                <P>2. Submit to FRA for approval a list of conductors and engineers who have been certified under the written programs approved by FRA, with complete, written certification determinations for each individual as required under 49 CFR 240.109 for engineers, and 49 CFR 242.109 for conductors.</P>
                <P>3. Submit to FRA for approval a written program of operational tests and inspections to be put in effect in accordance with 49 CFR 217.9.</P>
                <P>4. Submit to FRA for approval a training program in compliance with 49 CFR part 243 for training, qualification, and oversight of safety-related railroad employees.</P>
                <P>5. Submit to FRA for approval an on-track safety program that complies with the requirements of 49 CFR part 214, subpart C, and complete training and qualification records in accordance with that program for all employees who will engage in any on-track work or use of roadway maintenance machines.</P>
                <P>6. Submit to FRA a list of designated, qualified persons responsible for maintenance and inspection of track in accordance with 49 CFR 213.7.</P>
                <P>7. Accompany FRA track inspectors on a joint inspection of all BNGR track.</P>
                <P>8. Complete all remedial actions noted by FRA for track defects identified following the joint inspection and submit records of all required track inspections after the completion of all remedial action.</P>
                <P>9. Certify to FRA that a self-audit of HOS records has been completed and submit to FRA any records found to be incorrect or substantially incomplete with corrections to those records, to the extent possible.</P>
                <P>10. Certify to FRA that all employees have been trained on HOS requirements under 49 CFR part 228; 49 U.S.C. ch. 211.</P>
                <P>11. Certify to FRA that all employees have been trained on the requirements under 49 CFR part 225 to report accidents and incidents to FRA.</P>
                <P>12. Submit to FRA all records of inspections required to be maintained under § 234.109 (system malfunction at highway-rail grade crossings).</P>
                <P>13. Certify that all locomotives are in proper condition and fit for service in accordance with 49 U.S.C. ch. 207 and 49 CFR part 229.</P>
                <P>14. Obtain approval from the FRA Administrator that all requirements of this Order have been met and properly performed.</P>
                <P>
                    To obtain relief, BNGR must take the actions described above and submit all required information and certifications to 
                    <E T="03">Christian.Holt@dot.gov</E>
                     and subsequently inform the FRA Administrator in writing that it believes all of the requirements of this Order have been met. FRA will conduct verification inspections and will inform BNGR in writing whether it is in compliance with this Order so that the Order may be lifted. If FRA does not lift the Order, FRA's written response will specifically describe what additional measures need to be taken to meet all of the requirements of this Order.
                </P>
                <HD SOURCE="HD1">Partial Relief</HD>
                <P>
                    For FRA to consider granting partial relief from this Order, BNGR must submit a written plan for approval to 
                    <E T="03">Christian.Holt@dot.gov</E>
                     that provides a detailed explanation of the partial relief sought, the specific measures that BNGR proposes to ensure the safety of any operations to be permitted, and the period of time for which such partial relief is sought.
                </P>
                <P>Any partial relief provided will remain subject to BNGR's compliance with its approved written plan to provide safety measures, limitations on operations, and time periods for each component part of the partial relief. Failure to comply with any material provision of the approved plan will result in the partial relief being revoked.</P>
                <HD SOURCE="HD1">Penalties</HD>
                <P>Any violation of this Order or the terms of any approved written plan pursuant to this Order subjects the person (railroad carrier) committing the violation to a civil penalty of up to $35,516 for ordinary violations and $142,063 for aggravated violations for each day the violation continues. 49 U.S.C. 21301; 88 FR 89551 (Dec. 28, 2023). Any individual (railroad personnel) who willfully violates a provision stated in this Order is subject to civil penalties under 49 U.S.C. 21301. In addition, such an individual (railroad personnel) whose violation of this Order demonstrates the individual's unfitness for safety-sensitive service may be removed from safety-sensitive service on the railroad under 49 U.S.C. 20111.</P>
                <P>If appropriate, FRA may pursue criminal penalties under 49 U.S.C. 522(a) and 49 U.S.C. 21311(a), as well as 18 U.S.C. 1001, for the knowing and willful falsification of a report required by this Order. FRA may, through the Attorney General, also seek injunctive relief to enforce this Order. 49 U.S.C. 20112.</P>
                <HD SOURCE="HD1">Effective Date and Notice to Affected Persons</HD>
                <P>
                    This Order takes effect at 12:01 a.m., C.S.T., on February 3, 2024, and applies to operations of all trains, locomotives, and any other on-track rail vehicles or equipment. Notice of this Order will be provided by publishing it in the 
                    <E T="04">Federal Register</E>
                    . Copies of this Order will be sent by email prior to publication to BNGR, ODOT, and BIA.
                </P>
                <HD SOURCE="HD1">Review</HD>
                <P>
                    Opportunity for formal review of this Order will be provided in accordance with 49 U.S.C. 20104(b) and 5 U.S.C. 554. Administrative procedures governing such review are found at 49 CFR part 211. 
                    <E T="03">See</E>
                     49 CFR 211.47, 211.71, 211.73, 211.75, and 211.77.
                </P>
                <SIG>
                    <DATED>Issued in Washington, DC, on February 2, 2024.</DATED>
                    <NAME>Amitabha Bose,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02536 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Transit Administration</SUBAGY>
                <SUBJECT>FY 2024 Competitive Funding Opportunity: Low or No Emission Grant Program and the Grants for Buses and Bus Facilities Competitive Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Transit Administration (FTA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of funding opportunity (NOFO).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Federal Transit Administration (FTA) announces the opportunity to apply for approximately $1.10 billion in competitive grants under the fiscal year (FY) 2024 Low or No Emission Grant Program (Low-No Program) (Federal Assistance Listing: 20.526) and approximately $390 million in competitive grants under the FY 2024 Grants for Buses and Bus Facilities Program (Buses and Bus Facilities Program) (Federal Assistance Listing 20.526), subject to availability of appropriated funding.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        Complete proposals must be submitted electronically through the 
                        <E T="03">GRANTS.GOV</E>
                         “APPLY” function by 11:59 p.m. eastern time on April 25, 2024. Prospective applicants should initiate the process by registering on the 
                        <E T="03">GRANTS.GOV</E>
                         website promptly to ensure completion of the application process before the submission deadline.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Instructions for applying can be found on FTA's website at 
                        <E T="03">https://www.transit.dot.gov/howtoapply</E>
                         and in the “FIND” module of 
                        <E T="03">GRANTS.GOV</E>
                        . The funding opportunity ID is FTA-2024-003-TPM-
                        <PRTPAGE P="8742"/>
                        LWNO for Low-No applications and FTA-2024-004-TPM-BUS for Buses and Bus Facilities applications. Please note, if an applicant is choosing to apply to both programs, the applicant must submit a separate 
                        <E T="03">GRANTS.GOV</E>
                         package to each opportunity ID. Applicants should also select both programs and respond to all questions needed for both programs on the supplemental form. Mail and fax submissions will not be accepted.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Either Program may be contacted by email at 
                        <E T="03">FTALowNoBusNOFO@dot.gov,</E>
                         or applicants may call Kirsten Wiard-Bauer, FTA Office of Program Management, at 202-366-7052.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>As required by Federal public transportation law, Low-No Program funds will be awarded competitively for the purchase or lease of low or no emission vehicles that use advanced technologies for transit revenue operations, including related equipment or facilities. As required by Federal public transportation law, Buses and Bus Facilities Program funds will be awarded competitively to assist in the financing of capital projects to replace, rehabilitate, purchase, or lease buses and related equipment, and to rehabilitate, purchase, construct or lease bus-related facilities. Any zero-emission project(s) or components of a project will include costs for workforce development, unless the applicant certifies funds are not needed for this purpose. In general, projects may include costs incidental to the acquisition of buses or to the construction of facilities, such as the costs of related workforce development and training activities, and project administration expenses, as long as the project proposed includes and results in an eligible capital asset being leased, purchased, or built. As these two programs have overlapping eligibilities and must be implemented on the same timeline as required by 49 U.S.C. 5339, FTA is publishing this joint NOFO. Per Federal public transportation law, FTA will award grants for these programs within 75 days after the date this solicitation expires from funds available for award at that time. FTA may award additional funding that is made available to the programs prior to the announcement of project selections.</P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s50,r200">
                    <TTITLE>Summary Overview of Key Information: Low or No Emission (Low-No) Program and the Grants for Buses and Bus Facilities Competitive (Buses and Bus Facilities) Program</TTITLE>
                    <BOXHD>
                        <CHED H="1">Issuing agency</CHED>
                        <CHED H="1">Federal Transit Administration, US Department of Transportation</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Program Overview</ENT>
                        <ENT>
                            The 
                            <E T="03">Low-No Program</E>
                             provides funding for the purchase or lease of zero-emission and low-emission transit buses, including acquisition, construction, and leasing of required supporting facilities such as recharging, refueling, and maintenance facilities.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            The 
                            <E T="03">Buses and Bus Facilities Program</E>
                             provides funding for capital projects to replace, rehabilitate, purchase, or lease buses and related equipment, or to rehabilitate, purchase, construct, or lease bus-related facilities.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Eligible Applicants</ENT>
                        <ENT>
                            <E T="03">Low-No Program:</E>
                             Designated recipients, States (including territories and Washington, DC), local governmental authorities, and Indian tribes. Proposals for funding projects in rural areas must be submitted as part of a State application.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            <E T="03">Buses and Bus Facilities Program:</E>
                             Designated recipients that allocate funds to fixed route bus operators, States (including territories and Washington, DC), or local governmental entities that operate fixed route bus service, and Indian tribes. Eligible subrecipients include all otherwise eligible applicants and also private nonprofit organizations engaged in public transportation.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Eligible Project Types</ENT>
                        <ENT>
                            <E T="03">Low-No Program:</E>
                            <LI>• Purchase or lease low or no emission buses;</LI>
                            <LI>• Acquiring low or no emission buses with a leased power source;</LI>
                            <LI>• Constructing or leasing facilities and related equipment (including intelligent technology and software) for low or no emission buses;</LI>
                            <LI>• Constructing new public transportation facilities to accommodate low or no emission buses;</LI>
                            <LI>• Rehabilitating or improving existing public transportation facilities to accommodate low or no emission buses;</LI>
                            <LI>• Additionally, 0.5% of the Federal request may be used for workforce development training and an additional 0.5% may be used for training at the National Transit Institute (NTI). Note, applicants proposing any project related to zero-emission vehicles and related facilities must also spend 5% of their award on workforce development and training as outlined in their Zero-Emission Fleet Transition Plan, unless the applicant certifies that their financial need is less.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            <E T="03">Buses and Bus Facilities Program:</E>
                            <LI>• Capital projects to replace, rehabilitate, purchase, or lease buses, vans, or related equipment;</LI>
                            <LI>• Rehabilitate, purchase, construct, or lease bus-related facilities regardless of propulsion type or emissions;</LI>
                            <LI>• Additionally, 0.5% of the Federal request may be used for workforce development training and an additional 0.5% may be used for training at the National Transit Institute (NTI). Note, applicants proposing any project related to zero-emission vehicles and related facilities must also spend 5% of their award on workforce development and training as outlined in their Zero-Emission Fleet Transition Plan, unless the applicant certifies that their financial need is less.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Funding</ENT>
                        <ENT>
                            <E T="03">Low-No Program:</E>
                             $1,103,963,762.
                            <LI>
                                <E T="03">Buses and Bus Facilities Program:</E>
                                 $390,045,823.
                            </LI>
                            <LI>Additional funds made available prior to project selection may be allocated to eligible projects.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Deadline</ENT>
                        <ENT>April 25, 2024 at 11:59 p.m. eastern time.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">A. Program Description</FP>
                    <FP SOURCE="FP-2">B. Federal Award Information</FP>
                    <FP SOURCE="FP-2">C. Eligibility Information</FP>
                    <FP SOURCE="FP-2">D. Application and Submission Information</FP>
                    <FP SOURCE="FP-2">E. Application Review Information</FP>
                    <FP SOURCE="FP-2">F. Federal Award Administration Information</FP>
                    <FP SOURCE="FP-2">G. Federal Awarding Agency Contacts</FP>
                    <FP SOURCE="FP-2">H. Other Information</FP>
                </EXTRACT>
                <HD SOURCE="HD1">A. Program Description</HD>
                <P>This is a joint NOFO that announces the availability of FY 2024 funding for both the Low-No and the Buses and Bus Facilities Programs.</P>
                <P>
                    Federal public transportation law (49 U.S.C. 5339(c)) authorizes FTA to award grants for low or no emission bus projects through a competitive process, as described in this notice. The Low-No 
                    <PRTPAGE P="8743"/>
                    Program provides funding to States (including territories and Washington, DC), local governmental authorities, and tribal governments for the purchase or lease of zero-emission and low-emission transit buses, including acquisition, construction, and leasing of required supporting facilities such as recharging, refueling, and maintenance facilities.
                </P>
                <P>Federal public transportation law (49 U.S.C. 5339(b)) authorizes FTA to award grants for the Buses and Bus Facilities Program through a competitive process, as described in this notice. Grants under this program are for capital projects to replace, rehabilitate, purchase, or lease buses and related equipment, or to rehabilitate, purchase, construct, or lease bus-related facilities.</P>
                <P>
                    The Department seeks to fund projects under the Low-No and the Buses and Bus Facilities Programs that reduce greenhouse gas emissions in the transportation sector; incorporate evidence-based climate resilience measures and features; avoid adverse environmental impacts to air or water quality, wetlands, and endangered species; and address the disproportionate negative environmental impacts of transportation on disadvantaged communities, consistent with Executive Order 14008, 
                    <E T="03">Tackling the Climate Crisis at Home and Abroad</E>
                     (86 FR 7619).
                </P>
                <P>
                    In addition, the Department seeks to fund projects under the Low-No and the Buses and Bus Facilities Programs that create proportional impacts to all populations in a project area, remove transportation related disparities to all populations in a project area, and increase equitable access to project benefits, consistent with Executive Order 13985, 
                    <E T="03">Advancing Racial Equity and Support for Underserved Communities Through the Federal Government</E>
                     (86 FR 7009). The Department also seeks to award projects that address equity and environmental justice, particularly for communities that have experienced decades of underinvestment and are most impacted by climate change, pollution, and environmental hazards, consistent with Executive Order 14008, 
                    <E T="03">Tackling the Climate Crisis at Home and Abroad</E>
                     (86 FR 7619). In addition, the Department intends to use the Low-No and the Buses and Bus Facilities Programs to support the creation of good-paying jobs with the free and fair choice to join a union and the incorporation of strong labor standards and training and placement programs, especially registered apprenticeships, in project planning stages, consistent with Executive Order 14025, 
                    <E T="03">Worker Organizing and Empowerment</E>
                     (86 FR 22829) and Executive Order 14052, 
                    <E T="03">Implementation of the Infrastructure Investment and Jobs Act</E>
                     (86 FR 64335). The Department also intends to use the Low-No and the Buses and Bus Facilities Programs to support wealth creation, consistent with the Department's Equity Action Plan (
                    <E T="03">https://www.transportation.gov/priorities/equity/equity-action-plan</E>
                    ), through the inclusion of local inclusive economic development and entrepreneurship such as the utilization of Disadvantaged Business Enterprises.
                </P>
                <P>In order to support efficient and cost-effective vehicle procurements, FTA will provide priority consideration to applicants that identify their intent to use a procurement method that reduces vehicle customization, by either: identifying an intent for a joint procurement with at least three total transit agencies using a common specification; or committing to using a standard vehicle model. To strengthen the American vehicle manufacturing industry and reduce the financial burden the industry currently faces, FTA will give priority consideration to applicants that identify their intent to use contract terms that provide funding to vehicle original equipment manufacturer (OEMs) earlier in the production process, either by using advance payments or progress payments.</P>
                <HD SOURCE="HD1">B. Federal Award Information</HD>
                <P>Federal public transportation law (49 U.S.C. 5338(a)(2)(N)) authorizes $74,963,762 in FY 2024 for the Low-No Program. The 2021 Bipartisan Infrastructure Law (BIL) (enacted as the Infrastructure Investment and Jobs Act, Pub. L. 117-58) provided an additional $1,029,000,000 in advance appropriations for FY 2024 grants after accounting for the authorized takedown for administrative and oversight expenses and the Office of Inspector General (OIG). A grand total of $1,103,963,762 is being made available for the FY 2024 Low-No Program under this notice, subject to appropriations. Additional funds made available prior to project selection may be allocated to eligible projects.</P>
                <P>As required by Federal public transportation law (49 U.S.C. 5339(c)(5)), a minimum of 25 percent of the amount awarded under the Low-No Program will be awarded to low-emission projects other than zero-emission vehicles and related facilities. For FY 2024, $275,990,941 is specifically set aside by law for low-emission projects through the Low-No Program.</P>
                <P>In FY 2023, the Low-No program received applications for 210 projects requesting a total of $4,199,934,378. Eighty-three projects were funded for a total of $1,216,941,396.</P>
                <P>Federal public transportation law (49 U.S.C. 5338(a)(2)(N)) authorizes $393,559,749 in FY 2024 funds for the Buses and Bus Facilities Program. After the oversight takedown of $3,513,926, FTA is announcing the availability of $390,045,823 for the Buses and Bus Facilities Program through this notice, subject to appropriations. Additional funds made available prior to project selection may be allocated to eligible projects.  </P>
                <P>As required by Federal public transportation law at 49 U.S.C. 5339(b)(5), a minimum of 15 percent of the amount awarded under the Buses and Bus Facilities Program will be awarded to projects located in rural areas. As required by 49 U.S.C. 5339(b)(8), no single grant recipient will be awarded more than 10 percent of the amount made available. In FY 2023, the program received applications for 265 projects requesting a total of $4,492,423,860. Forty-seven projects were funded for a total of $472,922,707.</P>
                <P>
                    An applicant may submit a project to both the Buses and Bus Facilities Program and the Low-No Program, or submit the project only to the Low-No Program or only to the Buses and Bus Facilities Program. Applicants are encouraged to submit projects for consideration under both programs whenever practicable. A project submitted to both programs must be eligible in its entirety under both programs, and therefore must be a low or no emission project with no standard propulsion vehicles or facilities and equipment unrelated to low or no emission bus implementation, and must request or provide a scalable amount of no more than the equivalent of 10 percent of the funding available under the Buses and Bus Facilities Program. If a project submitted for consideration under both programs is selected for funding, FTA will exercise its discretion to determine under which program the project will receive an award. Please note that if submitting to both programs, the application package must be submitted twice at 
                    <E T="03">GRANTS.GOV</E>
                    , once to funding opportunity ID FTA-2024-003-TPM-LWNO for Low-No and once to FTA-2024-004-TPM-BUS for Buses and Bus Facilities. If there are not enough eligible requests for either the low-emission set-aside under the Low-No Program or the rural set-aside under the Buses and Bus Facilities Program, and eligible applications that would qualify under either of those set-asides 
                    <PRTPAGE P="8744"/>
                    were submitted only to the other program, FTA may contact such applicants to request additional information in order to consider them under the program for which they would satisfy a statutory set-aside.
                </P>
                <P>FTA may cap the amount a single recipient or State may receive as part of the selection process for either program.</P>
                <P>FTA will grant pre-award authority to incur costs for selected projects beginning on the date FY 2024 project selections are announced on FTA's website. Funds are available for obligation for three fiscal years after the fiscal year in which the competitive awards are announced. Funds are available only for eligible costs incurred after announcement of project selections. FTA intends to fund as many meritorious projects as possible.</P>
                <HD SOURCE="HD1">C. Eligibility Information</HD>
                <HD SOURCE="HD2">1. Eligible Applicants</HD>
                <P>Eligible applicants for the Low or No Emission Program include designated recipients, States (including territories and Washington, DC), local governmental authorities, and Indian tribes. To be considered eligible, applicants must be able to demonstrate the requisite legal, financial, and technical capabilities to receive and administer Federal funds under this program. Assistance on this requirement is available from FTA's Regional Offices.</P>
                <P>Eligible applicants for the Buses and Bus Facilities Program include designated recipients that allocate funds to fixed route bus operators, States (including territories and Washington, DC), or local governmental entities that operate fixed route bus service, and Indian tribes. Eligible subrecipients include all otherwise eligible applicants and also private nonprofit organizations engaged in public transportation. Eligible subrecipients are not required to operate fixed route bus service.</P>
                <P>Except for projects proposed by Indian tribes, all proposals for projects in rural (non-urbanized) areas—defined as any area that has not been designated in the 2020 Census as an “urban area” with at least 50,000 in population by the Secretary of Commerce—must be submitted by a State, either individually or as part of a consolidated State application. States and other eligible applicants may also submit consolidated proposals for projects in urbanized areas. The submission of a statewide or consolidated urbanized area application does not preclude any other eligible recipients in an urbanized area or in a State from also submitting a separate application. Proposals may contain projects to be implemented by the recipient or its subrecipients.</P>
                <P>As permitted under Federal public transportation law (49 U.S.C. 5339(b)(10), (c)(8)), an applicant proposing a low or no emission project under both the Buses and Bus Facilities Program and the Low-No Program, or an applicant proposing only a low or no emission project under the Low-No program, may include partnerships with other entities that intend to participate in the implementation of the project, including, but not limited to, specific vehicle manufacturers, equipment vendors, owners or operators of related facilities, or project consultants. If an application that involves such a partnership is selected for funding, the project will be deemed to satisfy the requirement for a competitive procurement under 49 U.S.C. 5325(a) for the named entities. Applicants are advised that any changes to the proposed partnership will require FTA written approval, must be consistent with the scope of the approved project, and may necessitate a competitive procurement.</P>
                <HD SOURCE="HD2">2. Cost Sharing or Matching</HD>
                <P>The maximum Federal share for projects that involve leasing or acquiring transit buses (including clean fuel or alternative fuel vehicles) for purposes of complying with or maintaining compliance with the Clean Air Act (CAA) or the Americans with Disabilities Act (ADA) of 1990 is 85 percent of the net project cost.</P>
                <P>The maximum Federal share for the cost of acquiring, installing, or constructing vehicle-related equipment or facilities (including clean fuel or alternative fuel vehicle-related equipment or facilities) for purposes of complying with or maintaining compliance with the CAA or ADA is 90 percent of the net project cost of such equipment or facilities that are attributable to compliance with the CAA or ADA. The award recipient must itemize the cost of specific, discrete, vehicle-related equipment or facility components associated with compliance with the CAA or ADA to be eligible for the maximum 90 percent Federal share for these costs. The Federal share of the cost of other projects shall not exceed 80 percent.</P>
                <P>
                    Eligible sources of match include the following: cash from non-Government sources other than revenues from providing public transportation services; revenues derived from the sale of advertising and concessions; amounts received under a service agreement with a State or local social service agency or private social service organization; revenues generated from value capture financing mechanisms; funds from an undistributed cash surplus; replacement or depreciation cash fund or reserve; new capital; or in-kind contributions. Transportation development credits or in-kind match may be used for local match if identified and documented in the application. Other Federal funds from non-U.S. Department of Transportation sources may only be used as match (Federal fund braiding) if the proposed project is eligible under the other Federal program and the other Federal program providing the matching funds expressly authorizes its funds to fulfill the match requirement of other Federal programs. Learn more about Federal fund braiding at 
                    <E T="03">https://www.transit.dot.gov/regulations-and-programs/ccam/about/coordinating-council-access-and-mobility-ccam-federal-fund.</E>
                </P>
                <HD SOURCE="HD2">3. Eligible Projects</HD>
                <P>Under the Low-No Program (49 U.S.C. 5339(c)), eligible projects include projects or programs of projects in an eligible area for: (1) purchasing or leasing low or no emission buses; (2) acquiring low or no emission buses with a leased power source; (3) constructing or leasing facilities and related equipment for low or no emission buses; (4) constructing new public transportation facilities to accommodate low or no emission buses; or (5) rehabilitating or improving existing public transportation facilities to accommodate low or no emission buses (49 U.S.C. 5339(c)(1)(B)). As required by Federal public transportation law (49 U.S.C. 5339(c)(5)), FTA will consider only eligible projects relating to the acquisition or leasing of low or no emission buses or bus facilities that make greater reductions in energy consumption and harmful emissions than comparable standard buses or other low or no emission buses. A single application may include both vehicle and facility components, along with associated equipment and workforce development plans.  </P>
                <P>
                    A low or no emission bus is defined as a passenger vehicle used to provide public transportation that sufficiently reduces energy consumption or harmful emissions, including direct carbon emissions, when compared to a standard vehicle. The statutory definition includes zero-emission transit buses, which are defined as buses that produce no direct carbon emissions and no particulate matter emissions under any and all possible operational modes and conditions. Examples of zero-emission bus technologies include, but are not limited to, hydrogen fuel-cell 
                    <PRTPAGE P="8745"/>
                    buses, battery-electric buses, and rubber tire trolley buses powered by overhead catenaries. All new transit bus models must successfully complete FTA bus testing for production transit buses pursuant to FTA's Bus Testing regulation (49 CFR part 665) in order to be procured with funds awarded under the Low-No Program. All transit vehicles must be procured from certified transit vehicle manufacturers in accordance with the Disadvantaged Business Enterprise (DBE) regulations (49 CFR part 26). The development or deployment of prototype vehicles is not eligible for funding under the Low-No Program.
                </P>
                <P>Eligible projects for the Buses and Bus Facilities Program include capital projects to replace, rehabilitate, purchase, or lease buses, vans, or related equipment; or to rehabilitate, purchase, construct, or lease bus-related facilities regardless of propulsion type or emissions. A single application may include both vehicle and facility components, along with associated equipment and workforce development activities.</P>
                <P>
                    Recipients are permitted to use up to 0.5 percent of their requested grant award for workforce development activities eligible under Federal public transportation law (49 U.S.C. 5314(b)), including on-the-job training, labor-management partnership training, and registered apprenticeships, and an additional 0.5 percent for costs associated with training at the National Transit Institute. Supportive services are an eligible use of program funds under 49 U.S.C. 5314(b). Supportive services are critical to help women and people facing systemic barriers to employment be able to participate and thrive in training and employment. Supportive services include childcare, tools, work clothing, application fees and other costs of apprenticeship or required pre-employment training, transportation and travel to training and work sites, and services aimed at helping to retain underrepresented groups such as mentoring, support groups, and peer networking. See: 
                    <E T="03">https://www.transit.dot.gov/funding/grants/federal-transit-administration-faqs-supportive-services.</E>
                </P>
                <P>For applicants proposing any project related to zero-emission vehicles (including vehicles, facilities, equipment, etc.) for either program, 5 percent of the total requested Federal amount attributable to zero-emission project components, including the workforce development activities but not including the required local share, must be used for workforce development to retrain the existing workforce and develop the workforce of the future, including registered apprenticeships and other joint labor-management training programs, as outlined in the applicant's Zero-Emission Transition Plan (see Section E(1)(c) of this notice), as well as supportive services, unless the applicant certifies via the application that less funding is needed to carry out the Plan. Applicants must identify the proposed use of funds for these activities in the project proposal and identify them separately in the project budget. These amounts are additional, not a take-down, from other eligible project expenses. For example, if an application includes a Federal request of $95,000 for total capital costs of zero-emission vehicles and associated equipment, an additional Federal request of $5,000 should be included in the budget for workforce development expenses for a total Federal request of $100,000. The local share for the vehicles, equipment, and workforce development is in addition to the $100,000 Federal request. Applicants are encouraged to discuss training needs with their workforce and to develop training plans in collaboration with unions and other workforce representatives, as well as with workforce boards, community colleges, and other workforce organizations. Applicants that propose not to use the full 5 percent available must include an explanation as to why the funds are not needed.</P>
                <P>If a single project proposal involves multiple public transportation providers, such as when an agency acquires vehicles that will be operated by another agency, the proposal must include a detailed statement regarding the role of each public transportation provider in the implementation of the project.</P>
                <HD SOURCE="HD1">D. Application and Submission Information</HD>
                <HD SOURCE="HD2">1. Address to Request Application Package</HD>
                <P>
                    Applications must be submitted electronically through 
                    <E T="03">GRANTS.GOV</E>
                    . General information for accessing and submitting applications through 
                    <E T="03">GRANTS.GOV</E>
                     can be found at 
                    <E T="03">https://www.transit.dot.gov/howtoapply</E>
                     along with specific instructions for the forms and attachments required for submission. Mail or fax submissions of completed proposals will not be accepted. A complete proposal submission for each program consists of two forms: the SF-424 Application for Federal Assistance (available at 
                    <E T="03">GRANTS.GOV</E>
                    ) and the supplemental form for the FY 2024 Low-No and Buses and Bus Facilities Programs (downloaded from 
                    <E T="03">GRANTS.GOV</E>
                     or the FTA website at 
                    <E T="03">https://www.transit.dot.gov/funding/grants/lowno</E>
                    ). The same supplemental form will be used to apply to either program or both programs. However, please note that if an applicant is applying to both programs, they must submit the materials through each of the 
                    <E T="03">GRANTS.GOV</E>
                     opportunity IDs listed for each program. Failure to submit the information as requested can delay review or disqualify the application.
                </P>
                <HD SOURCE="HD2">2. Content and Form of Application Submission</HD>
                <HD SOURCE="HD3">a. Proposal Submission</HD>
                <P>A complete proposal submission for each program consists of two forms: (1) the SF-424 Application for Federal Assistance; and (2) the supplemental form for the FY 2024 Low-No and Buses and Bus Facilities Programs. The supplemental form and any supporting documents must be attached to the “Attachments” section of the SF-424. The application must include responses to all sections of the SF-424 Application for Federal Assistance and the supplemental form, unless indicated as optional. The information on the supplemental form will be used to determine applicant and project eligibility for the program, and to evaluate the proposal against the selection criteria described in Section E of this notice.</P>
                <P>FTA will accept only one supplemental form per SF-424 submission. FTA encourages States and other applicants to consider submitting a single supplemental form that includes multiple activities to be evaluated as a consolidated proposal. If a State or other applicant chooses to submit separate proposals for individual consideration by FTA, each proposal must be submitted using a separate SF-424 and supplemental form.</P>
                <P>Applicants may attach additional supporting information to the SF-424 submission, including but not limited to letters of support, project budgets, fleet status reports, or excerpts from relevant planning documents. Applicants for zero-emission projects must attach the fleet transition plan. Any supporting documentation must be described and referenced by file name in the appropriate response section of the supplemental form, or it may not be reviewed.</P>
                <P>
                    Information such as applicant name, Federal amount requested, local match amount, description of areas served, etc. may be requested in varying degrees of detail on both the SF-424 and 
                    <PRTPAGE P="8746"/>
                    supplemental form. Applicants must fill in all fields unless stated otherwise on the forms. If information is copied into the supplemental form from another source, applicants should verify that pasted text is fully captured on the supplemental form and has not been truncated by the character limits built into the form. Applicants should use both the “Check Package for Errors” and the “Validate Form” validation buttons on both forms to check all required fields on the forms, and ensure that the Federal and local amounts specified are consistent. Applicants should enter their information in the supplemental form (fillable PDF) that is made available on FTA's website or through the 
                    <E T="03">GRANTS.GOV</E>
                     application package and should attach this to the application in its original format. Applicants should not use scanned versions of the form, “print” the form to PDF, convert or create a version using another text editor, etc.
                </P>
                <P>Projects proposed by Indian tribes that request less than $1 million in Federal funds do not need to provide a narrative response for the following criteria on the Supplemental Form: Demonstration of Benefits; Planning and Local/Regional Prioritization; Technical, Legal, and Financial Capacity; or any of Section IV Additional Considerations.</P>
                <P>The Department may share application information within the Department or with other Federal agencies if the Department determines that sharing is relevant to the respective program's objectives.</P>
                <HD SOURCE="HD3">b. Application Content  </HD>
                <P>The SF-424 Application for Federal Assistance and the supplemental form will prompt applicants for the required information, including:</P>
                <P>i. Applicant name.</P>
                <P>
                    ii. Unique Entity ID (UEI) assigned by 
                    <E T="03">SAM.GOV</E>
                    .
                </P>
                <P>iii. Key contact information (including contact name, address, email address, and phone).</P>
                <P>iv. Congressional district(s) where project will take place.</P>
                <P>v. Project information (including title, an executive summary, and type).</P>
                <P>vi. A detailed description of the need for the project.</P>
                <P>vii. A detailed description on how the project will support either Program's objectives.</P>
                <P>viii. Evidence that the project is consistent with local and regional planning documents.</P>
                <P>ix. Evidence that the applicant can provide the local cost share.</P>
                <P>x. A description of the technical, legal, and financial capacity of the applicant.</P>
                <P>xi. A detailed project budget identifying the amounts requested, amounts of other Federal funds, if any, and amounts of non-Federal funds.</P>
                <P>xii. An explanation of the scalability of the project—Applicants are encouraged to identify scaled funding options in case insufficient funding is available to fund a project at the full requested amount. If an applicant indicates that a project is scalable, the applicant must provide an appropriate minimum funding amount that will fund an eligible project that achieves the objectives of the program and meets all relevant program requirements. Proposed scalable projects must still result in a station or passenger facility with full accessibility to and usability by persons with disabilities, including persons who use wheelchairs. The applicant must provide a clear explanation of how the project budget would be affected by a reduced award. FTA may award a lesser amount regardless of whether a scalable option is provided.</P>
                <P>xiii. Details on the non-Federal matching funds.</P>
                <P>xiv. Details on any other Federal funds awarded or applied for.</P>
                <P>xv. A detailed project timeline.</P>
                <P>xvi. Address all the applicable criteria and priority considerations identified in Section E.</P>
                <P>Except for the information properly marked as described in Section H, the Department may share application information within the Department or with other Federal agencies if the Department determines that sharing is relevant to the respective program's objectives.</P>
                <HD SOURCE="HD2">3. Unique Entity Identifier and System for Award Management (SAM)</HD>
                <P>
                    Each applicant is required to: (1) be registered in 
                    <E T="03">SAM.GOV</E>
                     before submitting an application; (2) provide a valid unique entity identifier in its application; and (3) continue to maintain an active 
                    <E T="03">SAM.GOV</E>
                     registration with current information at all times during which the applicant has an active Federal award or an application or plan under consideration by FTA. These requirements do not apply if the applicant has an exemption approved by FTA pursuant to 2 CFR 25.110(c), or is otherwise excepted from registration requirements. FTA may not make an award until the applicant has complied with all applicable unique entity identifier and 
                    <E T="03">SAM.GOV</E>
                     requirements. If an applicant has not fully complied with the requirements by the time FTA is ready to make an award, FTA may determine that the applicant is not qualified to receive an award and use that determination as a basis for making a Federal award to another applicant.
                </P>
                <P>
                    All applicants must provide a unique entity identifier provided by 
                    <E T="03">SAM.GOV</E>
                    . Registration in 
                    <E T="03">SAM.GOV</E>
                     may take as little as 3-5 business days, but since there could be unexpected steps or delays (for example, if there is a need to obtain an Employer Identification Number), FTA recommends allowing ample time, up to several weeks, for completion of all steps. For additional information on obtaining a unique entity identifier, please visit 
                    <E T="03">https://www.sam.gov/.</E>
                </P>
                <HD SOURCE="HD2">4. Submission Dates and Times</HD>
                <P>
                    Project proposals must be submitted electronically through 
                    <E T="03">GRANTS.GOV</E>
                     by 11:59 p.m. Eastern time on April 25, 2024. 
                    <E T="03">GRANTS.GOV</E>
                     attaches a time stamp to each application at the time of submission. Proposals submitted after the deadline will only be considered under extraordinary circumstances not under the applicant's control. Mail and fax submissions will not be accepted.
                </P>
                <P>
                    Within 48 hours after submitting an electronic application, the applicant should receive an email message from 
                    <E T="03">GRANTS.GOV</E>
                     with confirmation of successful transmission to 
                    <E T="03">GRANTS.GOV</E>
                    . If a notice of failed validation or incomplete materials is received, the applicant must address the reason for the failed validation, as described in the email notice, and resubmit before the submission deadline. If making a resubmission for any reason, include all original attachments regardless of which attachments were updated and check the box on the supplemental form indicating this is a resubmission.
                </P>
                <P>
                    FTA urges applicants to submit applications at least 72 hours prior to the due date to allow time to receive the validation messages and to correct any problems that may have caused a rejection notification. 
                    <E T="03">GRANTS.GOV</E>
                     scheduled maintenance and outage times are announced on the 
                    <E T="03">GRANTS.GOV</E>
                     website. Deadlines will not be extended due to scheduled website maintenance.
                </P>
                <P>
                    Applicants are encouraged to begin the process of registration on the 
                    <E T="03">GRANTS.GOV</E>
                     site well in advance of the submission deadline. Registration is a multi-step process, which may take several weeks to complete before an application can be submitted. Registered applicants may still be required to take steps to keep their registrations up to date before submissions can be made successfully. For example, (1) registration in 
                    <E T="03">SAM.GOV</E>
                     is renewed annually, and (2) persons making 
                    <PRTPAGE P="8747"/>
                    submissions on behalf of the Authorized Organization Representative (AOR) must be authorized in 
                    <E T="03">GRANTS.GOV</E>
                     by the AOR to make submissions.
                </P>
                <HD SOURCE="HD2">5. Funding Restrictions</HD>
                <P>Funds under this NOFO cannot be used to reimburse applicants for otherwise eligible expenses incurred prior to FTA award of a grant agreement until FTA has issued pre-award authority for selected projects. FTA will issue pre-award authority to incur costs for selected projects beginning on the date that project selections are announced. FTA does not provide pre-award authority for competitive funds until projects are selected, and even then, there are Federal requirements that must be met before costs are incurred. FTA will issue specific guidance to awardees regarding pre-award authority at the time of selection. For more information about FTA's policy on pre-award authority, please see the most recent Apportionment Notice on FTA's website. Refer to Section C.3., Eligible Projects, for information on activities that are allowable in this grant program. Allowable direct and indirect expenses must be consistent with the Governmentwide Uniform Administrative Requirements and Cost Principles (2 CFR part 200) and FTA Circular 5010.1E. Funds may not be used to support or oppose union organizing.</P>
                <HD SOURCE="HD2">6. Other Submission Requirements</HD>
                <P>
                    All applications must be submitted via the 
                    <E T="03">GRANTS.GOV</E>
                     website. FTA does not accept applications on paper, by fax, email, or other means. For information on application submission requirements, please see Section D.1. of this notice, Address to Request Application.
                </P>
                <HD SOURCE="HD1">E. Application Review Information</HD>
                <HD SOURCE="HD2">1. Criteria</HD>
                <P>Projects will be evaluated primarily on the responses provided in the supplemental form. Additional information may be provided to support the responses; however, any additional documentation must be directly referenced on the supplemental form, including the file name where the additional information can be found. FTA will evaluate proposals based on the criteria described in this notice.  </P>
                <P>Projects proposed by Indian tribes that request less than $1 million in Federal funds only need to provide complete narrative responses to the Demonstration of Need and Local Financial Commitment criteria and a partial response to the Project Implementation Strategy criterion, consisting of a project timeline as well as (if applicable) a discussion on their proposed partner's qualifications. All applicants that are proposing a zero-emission project, including tribes requesting less than $1 million, are required by law to submit a Zero-Emission Fleet Transition Plan.</P>
                <P>If an applicant is proposing to deploy autonomous vehicles or other innovative motor vehicle technology, the application should demonstrate that all vehicles will comply with applicable safety requirements, including those administered by the National Highway Traffic Safety Administration (NHTSA) and Federal Motor Carrier Safety Administration (FMCSA). Specifically, the application should show that vehicles acquired for the proposed project will comply with applicable Federal Motor Vehicle Safety Standards (FMVSS) and Federal Motor Carrier Safety Regulations (FMCSR). If the vehicles may not comply, the application should either (1) show that the vehicles and their proposed operations are within the scope of an exemption or waiver that has already been granted by NHTSA, FMCSA, or both agencies or (2) directly address whether the project will require exemptions or waivers from the FMVSS, FMCSR, or any other regulation and, if the project will require exemptions or waivers, present a plan for obtaining them.</P>
                <HD SOURCE="HD3">a. Demonstration of Need</HD>
                <P>Since the purpose of these programs is to fund vehicles and facilities, applications will be evaluated based on the quality and extent to which they demonstrate how the proposed project will address an unmet need for capital investment in vehicles and/or supporting facilities. For example, an applicant may demonstrate that it requires additional or improved charging or maintenance facilities for low or no emission vehicles, that it intends to replace existing vehicles that have exceeded their minimum useful life, or that it requires additional vehicles to meet current ridership demands or expand services to better connect underserved communities.</P>
                <P>FTA will evaluate an applicant's responses to the following criteria when assessing the need for capital investment underlying the proposed project:</P>
                <P>
                    <E T="03">For bus projects (replacement or expansion):</E>
                </P>
                <P>For replacement requests, applicants must provide information on the age, condition, and performance of the vehicles to be replaced by the proposed project. Vehicles to be replaced must have met their minimum useful life at the time of project completion. For service expansion requests, applicants must provide information on the proposed service expansion and the benefits for transit riders and the community from the new service. For all vehicle projects, the proposal must address whether the project conforms to FTA's spare ratio guidelines. Vehicles funded under these programs are not exempt from FTA's standard spare ratio requirements, which apply to and are calculated based on the agency's entire fleet. Applicants that are introducing zero-emission vehicles into their fleet may consider including vehicles that have already met their minimum useful life in a contingency fleet, which is not included in the spare ratio calculation. Additionally, applicants who may need to exceed the spare ratio for a temporary period are encouraged to work with their FTA Regional Office to determine what flexibilities may be afforded to them and include reference to that in their application.</P>
                <P>
                    <E T="03">For bus facility and equipment projects (replacement, rehabilitation, or expansion):</E>
                </P>
                <P>For replacement requests, applicants must provide information on the age and condition of the asset to be rehabilitated or replaced relative to its minimum useful life. For expansion requests, applicants must provide information on the proposed expansion and the reason that transit riders and the community need the expansion.</P>
                <HD SOURCE="HD3">b. Demonstration of Benefits</HD>
                <HD SOURCE="HD3">i. Low or No Emissions Program</HD>
                <P>Applicants to the Low-No Program must demonstrate how the proposed project will support the statutory requirements of the Low-No Program (See 49 U.S.C. 5339(c)(5)(A)). In particular, FTA will evaluate the quality and extent to which applications demonstrate how the proposed project will: (1) Reduce Energy Consumption; (2) Reduce Harmful Emissions; and (3) Reduce Direct Carbon Emissions.</P>
                <P>
                    <E T="03">Reduce Energy Consumption:</E>
                     Applicants must describe how the proposed project will reduce energy consumption. FTA will evaluate applications based on the degree to which the proposed technology reduces energy consumption as compared to comparable standard vehicle propulsion technologies.
                </P>
                <P>
                    <E T="03">Reduce Harmful Emissions:</E>
                     Applicants must demonstrate how the proposed vehicles or facility will reduce the emission of particulates that create 
                    <PRTPAGE P="8748"/>
                    local air pollution, which leads to local environmental health concerns, smog, and unhealthy ozone concentrations. FTA will evaluate the rate of particulate emissions by the proposed vehicles or vehicles to be supported by the proposed facility, compared to the emissions from the vehicles that will be replaced or moved to the contingency fleet as a result of the proposed project, as well as comparable standard buses.
                </P>
                <P>
                    <E T="03">Reduce Direct Carbon Emissions:</E>
                     Applicants should demonstrate how the proposed vehicles or facility will reduce emissions of greenhouse gases from transit vehicle operations. FTA will evaluate the rate of direct carbon emissions by the proposed vehicles or vehicles to be supported by the proposed facility, compared to the emissions from the vehicles that will be replaced or moved to the contingency fleet as a result of the proposed project, as well as comparable standard buses.
                </P>
                <HD SOURCE="HD3">ii. Grants for Buses and Bus Facilities Program</HD>
                <P>Applicants to the Buses and Bus Facilities Program will be evaluated based on how well they describe how the proposed project will improve the safety of the transit system; improve the condition of, or otherwise modernize, the transit system; and enhance access and mobility within the service area, including improving reliability of service for riders, particularly for low-income or underserved communities and people with disabilities.</P>
                <P>
                    <E T="03">Safety:</E>
                     FTA will evaluate the potential for projects to provide positive safety benefits for all users, while not negatively impacting safety for all users. Applicants may describe how the project will reduce the frequency of safety events and/or improve the outcomes of safety events.
                </P>
                <P>
                    <E T="03">System Condition:</E>
                     FTA will evaluate the potential for replacement projects to improve the condition of the transit system by rehabilitating or replacing assets that are in poor condition or have surpassed their minimum or intended useful life benchmarks. Applicants may describe the benefits of reducing breakdowns and service interruptions; increasing service performance; and/or reducing the cost of maintaining outdated vehicles, facilities, and equipment.
                </P>
                <P>
                    <E T="03">Enhanced Access and Mobility:</E>
                     FTA will evaluate the potential for expansion projects to improve access and mobility for the transit riding public, particularly for low-income and underserved communities and people with disabilities, including improved headways, creation of new transportation choices, or eliminating gaps in the current route network. Proposed benefits should be based on documented ridership demand, based on indicators like area population density, employment served, and existing and planned affordable housing in the corridor, and be well-described or documented through a study or route planning proposal.
                </P>
                <P>Applicants that intend to apply to both programs must submit information that addresses the requirements of both programs as described above.</P>
                <HD SOURCE="HD3">c. Planning and Local or Regional Prioritization</HD>
                <P>
                    FTA will evaluate how the applicant demonstrates that the proposed project is consistent with local and regional long-range planning documents and local government priorities. FTA will evaluate applications based on the quality and extent to which the project is consistent with the transit priorities identified in the long-range plan for all proposals; contingency or illustrative projects included in that plan; or the locally developed human services public transportation coordinated plan. Applicants may submit copies of the relevant pages of such plans to support their application. FTA will consider how the project will support regional goals and applicants may submit support letters from local and regional planning organizations attesting to the consistency of the proposed project with these plans. Applicants are encouraged to also consult DOT's Promising Practices for Meaningful Public Involvement in Transportation Decision-Making at 
                    <E T="03">https://www.transportation.gov/priorities/equity/promising-practices-meaningful-public-involvement-transportation-decision-making.</E>
                </P>
                <P>Evidence of additional local or regional prioritization may include letters of support for the project from local government officials, public agencies, and non-profit or private sector supporters.  </P>
                <P>Applicants may also address how the proposed project will impact overall system performance, asset management performance, or specific performance measures tracked and monitored by the applying entity to demonstrate how the proposed project will address local and regional planning priorities.</P>
                <P>
                    For applications related to zero-emission vehicles (including vehicles, facilities, equipment, etc.) under either the Low-No or Buses and Bus Facilities programs, applicants are required by law (49 U.S.C. 5339(c)(3)(D)) to submit a Zero-Emission Fleet Transition Plan, including tribes that are requesting less than $1 million. This plan must be a separate document from other local or regional planning documents and must: (1) demonstrate a long-term fleet management plan with a strategy for how the applicant intends to use the current application and future acquisitions; (2) address the availability of current and future resources to meet costs for the transition and implementation; (3) consider policy and legislation impacting relevant technologies; (4) include an evaluation of existing and future facilities and their relationship to the technology transition; (5) describe the partnership of the applicant with the utility or alternative fuel provider; and (6) examine the impact of the transition on the applicant's current workforce by identifying skill gaps, training needs, and retraining needs of the existing workers of the applicant to operate and maintain zero-emission vehicles and related infrastructure and avoid the displacement of the existing workforce. FTA has developed resources for applicants regarding the development of this plan which can be found at 
                    <E T="03">https://www.transit.dot.gov/funding/grants/zero-emission-fleet-transition-plan.</E>
                     For agencies with smaller fleets, a fleet transition plan need not be complex and should be tailored as applicable, but it still must address all six elements. For applications from State departments of transportation, the State may either provide a fleet transition plan that covers some or all of the subrecipients, attach individual plans developed by the subrecipients, or a combination of both.
                </P>
                <HD SOURCE="HD3">d. Local Financial Commitment</HD>
                <P>
                    FTA will evaluate if the applicant identified the source of the local cost share and described whether such funds are currently available for the project or will need to be secured if the project is selected for funding. FTA will evaluate the availability of the local cost share as evidence of local financial commitment to the project. FTA will evaluate if the applicant submitted evidence of the availability of funds for the project; for example, by including a board resolution, letter of support from the State, a budget document highlighting the line item or section committing funds to the proposed project, or other documentation of the source of local funds. FTA will favorably view an applicant that proposes to use grant funds only for the incremental cost of new technologies over the cost of replacing vehicles with standard propulsion technologies. The applicant should also identify other Federal funds the applicant is applying for or has been 
                    <PRTPAGE P="8749"/>
                    awarded, if any, that the applicant intends to use.
                </P>
                <HD SOURCE="HD3">e. Project Implementation Strategy</HD>
                <P>FTA will rate projects higher if grant funds can be obligated within 12 months of selection and the project can be implemented within a reasonable time frame. In assessing when funds can be obligated, FTA will consider whether the project qualifies for a Categorical Exclusion (CE), or whether the required environmental work has been initiated or completed for projects that require an Environmental Assessment (EA) or Environmental Impact Statement (EIS) under the National Environmental Policy Act of 1969 (NEPA). As such, applicants should submit information describing the project's anticipated path and timeline through the environmental review process for all proposals, including those that may qualify for a CE. The proposal must state when grant funds can be obligated and indicate the timeframe under which the Metropolitan Transportation Improvement Program (TIP) and Statewide Transportation Improvement Program (STIP) can be amended to include the proposed project.</P>
                <P>In assessing whether the proposed implementation plans are reasonable and complete, FTA will review the proposed project implementation plan, including all necessary project milestones and the overall project timeline. For projects that will require formal coordination, approvals, or permits from other agencies or project partners, the applicant must demonstrate coordination with these organizations and their support for the project, such as through letters of support.</P>
                <P>Applicants that have identified a cooperative procurement strategy listed in Section 3019 of the Fixing America's Surface Transportation Act (Pub. L. 114-94; 49 U.S.C. 5325, note) are encouraged to describe the method chosen as part of their implementation plans and how such a cooperative procurement will reduce costs.</P>
                <P>For proposals that involve a partnership with a manufacturer, vendor, consultant, or other third party, applicants must identify by name any project partners, including, but not limited to, other transit agencies, bus manufacturers, owners or operators of related facilities, or any expert consultants. Such partnerships are permitted under Federal public transportation law (49 U.S.C. 5339(b)(10), (c)(8)) only for applicants proposing a low or no emission project under both the Buses and Bus Facilities Program and the Low-No Program, or for applicants proposing only a low or no emission project under the Low-No program. FTA will evaluate the experience and capacity of the named project partners to successfully implement the proposed project based on the partners' experience and qualifications. Applicants are advised to submit information on the partners' qualifications and experience as a part of the application. Entities to be involved in the project that are not named in the application must be selected through ordinary procurement processes.</P>
                <HD SOURCE="HD3">f. Technical, Legal, and Financial Capacity</HD>
                <P>FTA will evaluate if the applicant demonstrates that they have the technical, legal, and financial capacity to undertake the project.</P>
                <P>FTA will review relevant oversight assessments and records to determine whether there are any outstanding legal, technical, or financial issues with the applicant that would affect the outcome of the proposed project. Applicants with outstanding legal, technical, or financial compliance issues from an FTA compliance review or grant-related Single Audit finding must explain how corrective actions taken will mitigate negative impacts on the proposed project.</P>
                <HD SOURCE="HD2">2. Review and Selection Process</HD>
                <P>A technical evaluation committee will evaluate proposals based on the published evaluation criteria. FTA may request additional information from applicants, if necessary. Based on the review of the technical evaluation committee, the FTA Administrator will determine the final selection of projects for program funding. In determining the allocation of program funds, FTA may consider geographic diversity, diversity in the size of the transit systems receiving funding, whether an applicant is from a small urban or rural area or is a tribal government, and the applicant's receipt of other competitive awards. FTA may also consider capping the amount a single applicant may receive.</P>
                <P>After applying the above criteria, to support efficient and cost-effective vehicle procurements, FTA will provide priority consideration to applicants that identify their intent to use a procurement method that reduces vehicle customization, by either: identifying an intent for a joint procurement with at least three total transit agencies using a common specification; or, for low and no emission projects where the applicant proposes a vehicle OEM as a project partner, committing to using a standard vehicle model without customizations and including a letter from the vehicle OEM that certifies the applicant will use the OEM's standard model (see Section E.1.e. and Section C.1. of this notice for information on the partnership provision). The applicant should identify the proposed approach, other partners if applicable, and how the procurement approach reduces vehicle customization. FTA will evaluate each project on its own merits but may select an application that does not rate as highly as others if the applicant indicates its intent to pursue a joint procurement with other more highly rated participants in that procurement. FTA intends to weight this priority consideration greater than others.</P>
                <P>To strengthen the American vehicle manufacturing industry and reduce the financial burden the industry currently faces, FTA will give priority consideration to applicants that identify their intent to use contract terms that provide funding to vehicle OEMs earlier in the production process, either by using advance payments or progress payments. For applicants that identify their intent to use advance payments, FTA will not require securitization beyond the advance payment amount. The applicant should identify how their proposed contracting terms will expedite payments to vehicle OEMs. FTA also intends to weight this priority consideration greater than others. The contract terms of selected applications may be reviewed by FTA prior to award.  </P>
                <P>To address climate change and improve sustainability, FTA will give priority consideration to applications that are expected to create significant community benefits relating to the environment, including those projects that incorporate low or no emission technology or specific elements to address greenhouse gas emissions and climate change impacts. For facility projects, FTA will give priority consideration to applications that include elements to strengthen the resilience of the community and/or the transit system with regard to climate change.</P>
                <P>FTA will also prioritize a zero-emission project higher than other zero-emission projects if the applicant is able to demonstrate how the proposed project and fleet transition plan support the conversion of the agency's overall fleet to zero emissions.</P>
                <P>
                    Among vehicle applications that include at least 20 zero-emission 40-foot buses, FTA will give priority consideration to applications that identify greater emission reductions. To be considered for priority consideration, vehicle applications for at least 20 zero-
                    <PRTPAGE P="8750"/>
                    emission 40-foot buses must use the FTA Bus and Low-No Emission Reduction Calculator, which can be found at 
                    <E T="03">https://www.transit.dot.gov/funding/grants/fta-bus-and-low-no-emission-reduction-calculator,</E>
                     attach the file, and include the amount of reductions per vehicle in the supplemental form.
                </P>
                <P>Among zero-emission applications, FTA will give priority consideration to zero-emission applicants that are able to demonstrate that they have consulted with workforce representatives on all aspects of the workforce section of the fleet transition plan; and include steps to provide or connect workers to supportive services (such as childcare and transportation assistance); and identify the use of at least one of the following in their plan (1) use of labor-management partnerships for training; (2) use of registered apprenticeship training to support skilling of incumbent and entry-level workers with focus on using registered apprenticeship to advance Black, Hispanic, Asian American, Native Hawaiian and Pacific Islanders, tribal, women, and other groups facing systemic barriers to employment that may be underrepresented in the current workforce, especially in higher-paying jobs.</P>
                <P>FTA will also provide priority consideration for applicants that describe how their projects support workforce development, job quality, and wealth creation as follows:</P>
                <P>
                    Applicants for facility projects should identify whether they will commit to registered apprenticeship positions and use apprentices on the funded facility project, sometimes called an apprenticeship utilization requirement (
                    <E T="03">e.g.,</E>
                     requiring that a certain percent of all labor hours will be performed by registered apprentices); AND detail partnerships with high-quality workforce development programs with supportive services to help train, place, and retain underrepresented communities in jobs and registered apprenticeships on the facility project; and, for facility projects over $35 million in total project cost, whether the project will use a Project Labor/Community Workforce Agreement AND, for facility projects over $35 million, whether the recipient commits to participate in the U.S. Department of Labor's Office of Federal Contract Compliance Programs (OFCCP) Mega Construction Project Program if selected by OFCCP (see F.2.e. 
                    <E T="03">Federal Contract Compliance</E>
                    ).
                </P>
                <P>
                    FTA will also give priority consideration to projects that support the Justice40 initiative. In support of Executive Order 14008, DOT uses a geographic definition of Disadvantaged Communities as part of its implementation of the Justice40 Initiative. Consistent with the Interim Guidance for the Justice40 Initiative (see: 
                    <E T="03">https://www.transportation.gov/priorities/equity/justice40/resources</E>
                    ), Disadvantaged Communities include (a) certain qualifying census tracts identified as disadvantaged due to categories of environmental, climate, and socioeconomic burdens, as identified by the Climate and Economic Justice Screening Tool, and (b) any federally Recognized tribes or tribal entities, whether or not they have land. Applicants should use the Climate &amp; Economic Justice Screening Tool (CEJST), a tool created by the White House Council on Environmental Quality (CEQ), that aims to help Federal agencies identify disadvantaged communities as part of the Justice40 initiative to accomplish the goal that 40 percent of overall benefits from certain Federal investments reach disadvantaged communities. See 
                    <E T="03">https://screeningtool.geoplatform.gov/.</E>
                     Applicants should use the CEJST as the primary tool to identify disadvantaged communities (Justice40 communities). Applicants are strongly encouraged to supplement their use of the CEJST by employing the USDOT Equitable Transportation Community (ETC) Explorer to understand how their community or project area is experiencing disadvantage related to lack of transportation investments or opportunities. Through understanding how a community or project area is experiencing transportation-related disadvantage, applicants are able to address how the benefits of a project will reverse or mitigate the burdens of disadvantage and demonstrate how the project will address challenges and accrued benefits. See 
                    <E T="03">https://www.transportation.gov/priorities/equity/justice40/etc-explorer.</E>
                     Additionally, in support of the Justice40 Initiative, the applicant also should provide evidence of any strategies that the applicant has used in the planning process to seek out and consider the needs of those disadvantaged by existing transportation systems including public and community engagement. For technical assistance using either mapping tool, please contact 
                    <E T="03">GMO@dot.gov.</E>
                </P>
                <P>
                    Due to funding limitations, projects that are selected for funding may receive less than the amount originally requested, even if an application did not present a scaled project option. In those cases, applicants must be able to demonstrate that the proposed projects are still viable and can be completed with the amount awarded. See also 
                    <E T="03">https://static-data-screeningtool.geoplatform.gov/data-versions/1.0/data/score/downloadable/CEQ-CEJST-Instructions.pdf.</E>
                </P>
                <HD SOURCE="HD2">3. Integrity and Performance Review</HD>
                <P>
                    Prior to making an award with a total amount of Federal share greater than the simplified acquisition threshold (currently $250,000), FTA is required to review and consider any information about the applicant that is in the Federal Awardee Performance and Integrity Information Systems (FAPIIS) accessible through 
                    <E T="03">SAM.GOV</E>
                    . An applicant may review and comment on information about itself that a Federal awarding agency previously entered. FTA will consider any comments by the applicant, in addition to the other information in FAPIIS, in making a judgment about the applicant's integrity, business ethics, and record of performance under Federal awards when completing the review of risk posed by applicants as described in 2 CFR 200.206.
                </P>
                <HD SOURCE="HD1">F. Federal Award Administration Information</HD>
                <HD SOURCE="HD2">1. Federal Award Notices</HD>
                <P>FTA will announce the final project selections on the FTA website. Selectees should contact their FTA Regional Offices for additional information regarding allocations for projects. At the time the project selections are announced, FTA will extend pre-award authority for the selected projects (see Section D.5 of this notice for more information). There is no blanket pre-award authority for these projects before announcement.</P>
                <HD SOURCE="HD2">2. Administrative and National Policy Requirements</HD>
                <HD SOURCE="HD3">a. Grant Requirements</HD>
                <P>
                    If selected, awardees will apply for a grant through FTA's Transit Award Management System (TrAMS). Recipients of funding in urban areas according to the 2020 Census are subject to the grant requirements of the Urbanized Area Formula Grants program (49 U.S.C. 5307), including those of FTA Circular “Urbanized Area Formula Program: Program Guidance and Application Instructions” (FTA.C.9030.1E). Recipients of funding in rural areas according to the 2020 Census are subject to the grant requirements of the Formula Grants for Rural Areas Program (49 U.S.C. 5311), including those of FTA Circular “Formula Grants for Rural Areas: 
                    <PRTPAGE P="8751"/>
                    Program Guidance and Application Instructions” (FTA.C.9040.1G). All recipients must accept the FTA Master Agreement and follow FTA Circular “Award Management Requirements” (FTA.C.5010.1E) and the labor protections required by Federal public transportation law (49 U.S.C. 5333(b)). Technical assistance regarding these requirements is available from each FTA regional office.
                </P>
                <P>By submitting a grant application, the applicant assures that it will comply with all applicable Federal statutes, regulations, executive orders, directives, FTA circulars and other Federal administrative requirements in carrying out any project supported by the FTA grant, including the Davis-Bacon Act (40 U.S.C. 3141-3144, and 3146-3148) as supplemented by Department of Labor regulations (29 CFR part 5, “Labor Standards Provisions Applicable to Contracts Covering Federally Financed and Assisted Construction”). Further, the applicant acknowledges that it is under a continuing obligation to comply with the terms and conditions of the grant agreement issued for its project with FTA. The applicant understands that Federal laws, regulations, policies, and administrative practices might be modified from time to time and may affect the implementation of the project. The applicant agrees that the most recent Federal requirements will apply to the project unless FTA issues a written determination otherwise. The applicant must submit the Certifications and Assurances before receiving a grant if it does not have current certifications on file.</P>
                <P>
                    Applicants for the Buses and Bus Facilities Program are encouraged to utilize the innovative procurement practices found in Section 3019 of the Fixing America's Surface Transportation Act (49 U.S.C. 5325, note). Please see details at 
                    <E T="03">https://www.transit.dot.gov/funding/grants/innovative-procurement-leasing-fact-sheet-section-3019.</E>
                     If selected for funding, any project that purchases fewer than five buses through a standalone procurement must provide a written explanation why the tools authorized under Section 3019 were not utilized.
                </P>
                <P>As authorized by Section 25019 of the BIL, applicants are encouraged to implement a local or other geographical or economic hiring preference relating to the use of labor for construction of a project funded by the grant, including pre-hire agreements, subject to any applicable State and local laws, policies, and procedures.</P>
                <HD SOURCE="HD3">b. Buy America and Domestic Preferences for Infrastructure Projects</HD>
                <P>
                    As expressed in Executive Order 14005, 
                    <E T="03">Ensuring the Future Is Made in All of America by All of America's Workers</E>
                     (86 FR 7475), the Executive Branch should maximize, consistent with law, the use of goods, products, and materials produced in, and services offered in, the United States. Therefore, all capital procurements must comply with FTA's Buy America requirements (49 U.S.C. 5323(j)), which require that all iron, steel, and manufactured products be produced in the United States. In addition, any award must comply with the Build America, Buy America Act (BABA) (Pub. L. 117-58, sections 70901-27). BABA provides that none of the funds provided under an award made pursuant to this notice may be used for a project unless all iron, steel, manufactured products, and construction materials are produced in the United States. FTA's Buy America requirements are consistent with BABA requirements for iron, steel, and manufactured products.  
                </P>
                <P>Any proposal that will require a waiver of any domestic preference standard must identify the items for which a waiver will be sought in the application. Applicants should not proceed with the expectation that waivers will be granted.</P>
                <HD SOURCE="HD3">c. Civil Rights Requirements</HD>
                <P>As a condition of a grant award, grant recipients should demonstrate that the recipient has a plan for compliance with civil rights obligations and nondiscrimination laws, including Title VI of the Civil Rights Act of 1964 and implementing regulations (49 CFR part 21), the Americans with Disabilities Act of 1990 (ADA), and Section 504 of the Rehabilitation Act, all other civil rights requirements, and accompanying regulations. This should include a current Title VI plan, completed Community Participation Plan (alternatively called a Public Participation Plan and often part of the overall Title VI program plan), if applicable. DOT's and the applicable Operating Administrations' Office of Civil Rights may work with awarded grant recipients to ensure full compliance with Federal civil rights requirements.</P>
                <HD SOURCE="HD3">d. Disadvantaged Business Enterprise</HD>
                <P>Recipients of planning, capital, or operating assistance that will award prime contracts (excluding transit vehicle purchases), the cumulative total of which exceeds $250,000 in FTA funds in a Federal fiscal year, must comply with the Disadvantaged Business Enterprise (DBE) program regulations (49 CFR part 26).</P>
                <P>
                    To be eligible to bid on any FTA-assisted vehicle procurement, entities that manufacture transit vehicles or perform post-production alterations or retrofitting must be certified Transit Vehicle Manufacturers (TVM). If a vehicle remanufacturer is responding to a solicitation for new or remanufactured vehicles with a vehicle to which the remanufacturer has provided post-production alterations or retrofitting (
                    <E T="03">e.g.,</E>
                     replacing major components such as engine to provide a “like new” vehicle), the vehicle remanufacturer must be a certified TVM.
                </P>
                <P>
                    The TVM rule requires that, prior to bidding on any FTA-assisted vehicle procurement, manufacturers of transit vehicles submit a DBE Program plan and annual goal methodology to FTA. FTA then will issue a TVM concurrence and certification letter. Grant recipients must verify each manufacturer's TVM status before accepting its bid. A list of compliant, certified TVMs is posted on FTA's website at 
                    <E T="03">https://www.transit.dot.gov/TVM.</E>
                     Recipients should contact FTA before accepting a bid from a manufacturer not on this list. In lieu of using a certified TVM, a recipient may establish project-specific DBE goals for its vehicle procurement. FTA will provide additional guidance as grants are awarded. For more information on DBE requirements, please contact Monica McCallum, FTA Office of Civil Rights, 206-220-7519,
                    <E T="03"> Monica.McCallum@dot.gov.</E>
                </P>
                <HD SOURCE="HD3">e. Federal Contract Compliance</HD>
                <P>
                    As a condition of grant award and consistent with E.O. 11246, 
                    <E T="03">Equal Employment Opportunity</E>
                     (30 FR 12319, and as amended), all federally assisted construction contractors are required to make good faith efforts to meet the goals of 6.9 percent of construction project hours being performed by women, in addition to goals that vary based on geography for construction work hours and for work being performed by minorities. Under Section 503 of the Rehabilitation Act and its implementing regulations, affirmative action obligations for certain contractors include an aspirational employment goal of 7 percent workers with disabilities.
                </P>
                <P>
                    The U.S. Department of Labor's Office of Federal Contract Compliance Programs (OFCCP) is charged with enforcing Executive Order 11246, Section 503 of the Rehabilitation Act of 1973, and the Vietnam Era Veterans' Readjustment Assistance Act of 1974. OFCCP has a Mega Construction Project 
                    <PRTPAGE P="8752"/>
                    Program through which it engages with project sponsors as early as the design phase to help promote compliance with non-discrimination and affirmative action obligations. OFCCP may identify construction projects that receive an award under this notice that have a project cost above $35 million to participate in OFCCP's Mega Construction Project Program. If selected and the applicant agrees to participate, OFCCP will ask selected project sponsors to make clear to prime contractors in the pre-bid phase that award terms may require their participation in the Mega Construction Project Program. Additional information on how OFCCP makes their selections for participation in the Mega Construction Project Program is outlined under “Scheduling” on the Department of Labor website: 
                    <E T="03">https://www.dol.gov/agencies/ofccp/faqs/construction-compliance.</E>
                     As authorized by Section 25019 of the BIL, applicants are encouraged to implement a local or other geographical or economic hiring preference relating to the use of labor for construction of a project funded by the grant, including pre-hire agreements, subject to any applicable State and local laws, policies, and procedures.
                </P>
                <HD SOURCE="HD3">f. Critical Infrastructure Security, Cybersecurity, and Resilience</HD>
                <P>It is the policy of the United States to strengthen the security and resilience of its critical infrastructure against all hazards, including physical and cyber risks, consistent with Presidential Policy Directive 21—Critical Infrastructure Security and Resilience, and the National Security Memorandum on Improving Cybersecurity for Critical Infrastructure Control Systems. Each applicant selected for Federal funding must demonstrate, prior to the signing of the grant agreement, effort to consider and address physical and cyber security risks relevant to the transportation mode and type and scale of the project. Projects that have not appropriately considered and addressed physical and cyber security and resilience in their planning, design, and project oversight, as determined by the Department and the Department of Homeland Security, will be required to do so before receiving funds. FTA implements this requirement as follows:</P>
                <P>Pursuant to 49 U.S.C. 5323(v), a recipient that operates a rail fixed guideway public transportation system must certify that the recipient has established a process to develop, maintain, and execute a written plan for identifying and reducing cybersecurity risks. Recipients subject to this requirement must:</P>
                <P>1. Utilize the approach described by the voluntary standards and best practices developed under section 2(c)(15) of the National Institute of Standards and Technology Act (15 U.S.C. 272(c)(15)), as applicable;  </P>
                <P>2. Identify hardware and software that the recipient determines should undergo third-party testing and analysis to mitigate cybersecurity risks, such as hardware or software for rail rolling stock under proposed procurements; and</P>
                <P>3. Utilize the approach described in any voluntary standards and best practices for rail fixed guideway public transportation systems developed under the authority of the Secretary of Homeland Security, as applicable.</P>
                <P>
                    For information about standards or practices that may apply to a rail fixed guideway public transportation system, visit 
                    <E T="03">https://www.nist.gov/cyberframework</E>
                     and 
                    <E T="03">https://www.cisa.gov/.</E>
                </P>
                <P>TSA issued Security Directive 1582-21-01B, “Enhancing Public Transportation and Passenger Railroad Cybersecurity” on October 24, 2023. The Security Directive, which extends previous Security Directives, applies to all public passenger rail owners and operators identified in 49 CFR 1582.101, requires four critical actions:</P>
                <P>1. Designate a cybersecurity coordinator who is required to be available to TSA and the DHS's CISA at all times (all hours/all days) to coordinate implementation of cybersecurity practices, and manage of security incidents, and serve as a principal point of contact with TSA and CISA for cybersecurity-related matters;</P>
                <P>2. Report cybersecurity incidents to CISA;</P>
                <P>3. Develop a Cybersecurity Incident Response Plan to reduce the risk of operational disruption should their Information and/or operational technology systems be affected by a cybersecurity incident; and</P>
                <P>4. Conduct a cybersecurity vulnerability assessment using the form provided by TSA and submit the form to TSA. The vulnerability assessment will include an assessment of current practices and activities to address cyber risks to information and operational technology systems, identify gaps in current cybersecurity measures, and identify remediation measures and a plan for the owner/operator to implement the remediation measures to address any vulnerabilities and gaps.</P>
                <FP>Applicants subject to the Directive must certify compliance with the directive to receive the grant award.</FP>
                <P>In addition, TSA issued Information Circular IC-2021-01, “Enhancing Surface Transportation Cybersecurity”, dated December 31, 2021, which applies to each passenger railroad, public transportation agency, or rail transit system owner/operator identified in 49 CFR 1582.1. This circular provides the same four recommendations for enhancing cybersecurity practices listed above. While this document is guidance and does not impose any mandatory requirements, TSA strongly recommends the adoption of the measures set forth in the circular.</P>
                <P>
                    Finally, on February 10, 2023, FTA published a Cybersecurity Assessment Tool for Transit (CATT) (
                    <E T="03">https://www.transit.dot.gov/research-innovation/cybersecurity-assessment-tool-transit-catt</E>
                    ). This tool was developed with the goal to onboard public transit organizations develop and strengthen their cybersecurity program to identify risks and prioritize activities to mitigate these risks.
                </P>
                <HD SOURCE="HD3">g. Planning</HD>
                <P>FTA encourages applicants to notify the appropriate State Departments of Transportation and Metropolitan Planning Organizations (MPOs) in areas likely to be served by the project funds made available under this program. Selected projects must be incorporated into the long-range plans and transportation improvement programs of States and metropolitan areas before they are eligible for FTA funding.</P>
                <HD SOURCE="HD3">h. Performance and Program Evaluation</HD>
                <P>As a condition of grant award, grant recipients may be required to participate in an evaluation undertaken by DOT or another agency or partner. The evaluation may take different forms such as an implementation assessment across grant recipients, an impact and/or outcomes analysis of all or selected sites within or across grant recipients, or a benefit/cost analysis or assessment of return on investment. As a part of the evaluation, as a condition of award, grant recipients must agree to: (1) make records available to the evaluation contractor or DOT staff; (2) provide access to program records, and any other relevant documents to calculate costs and benefits; (3) in the case of an impact analysis, facilitate the access to relevant information as requested; and (4) follow evaluation procedures as specified by the evaluation contractor or DOT staff.</P>
                <P>
                    Recipients and subrecipients are also encouraged to incorporate program evaluation including associated data collection activities from the outset of their program design and implementation to meaningfully document and measure their progress 
                    <PRTPAGE P="8753"/>
                    towards meeting an agency priority goal(s). Title I of the Foundations for Evidence-Based Policymaking Act of 2018 (Evidence Act), Public Law 115-435 urges Federal awarding agencies and Federal assistance recipients and subrecipients to use program evaluation as a critical tool to learn, to improve equitable delivery, and to elevate program service and delivery across the program lifecycle. Evaluation means “an assessment using systematic data collection and analysis of one or more programs, policies, and organizations intended to assess their effectiveness and efficiency.” 5 U.S.C. 311. Credible program evaluation activities are implemented with relevance and utility, rigor, independence and objectivity, transparency, and ethics (OMB Circular A-11, part 6 section 290).
                </P>
                <HD SOURCE="HD2">3. Reporting</HD>
                <P>Post-award reporting requirements include the electronic submission of Federal Financial Reports and Milestone Progress Reports in FTA's electronic grants management system. Recipients of funds made available through this NOFO are also required to regularly submit data to the National Transit Database. Recipients should include any goals, targets, and indicators referenced in their applications in the Executive Summary of the TrAMS application.</P>
                <P>FTA is committed to making evidence-based decisions guided by the best available science and data. In accordance with the Foundations for Evidence-based Policymaking Act of 2018 (Evidence Act), FTA may use information submitted in discretionary funding applications; information in FTA's Transit Award Management System (TrAMS), including grant applications, Milestone Progress Reports (MPRs), Federal Financial Reports (FFRs); transit service, ridership and operational data submitted in FTA's National Transit Database; documentation and results of FTA oversight reviews, including triennial and State management reviews; and other publicly available sources of data to build evidence to support policy, budget, operational, regulatory, and management processes and decisions affecting FTA's grant programs.</P>
                <P>As part of completing the annual certifications and assurances required of FTA grant recipients, a successful applicant must report on the suspension or debarment status of itself and its principals. If the award recipient's active grants, cooperative agreements, and procurement contracts from all Federal awarding agencies exceeds $10,000,000 for any period of time during the period of performance of an award made pursuant to this Notice, the recipient must comply with the Recipient Integrity and Performance Matters reporting requirements described in Appendix XII to 2 CFR part 200.</P>
                <HD SOURCE="HD1">G. Federal Awarding Agency Contacts</HD>
                <P>
                    For further information concerning this notice, please email 
                    <E T="03">FTALowNoBusNOFO@dot.gov,</E>
                     or call Kirsten Wiard-Bauer, FTA Office of Program Management, at 202-366-7052. A TDD is available for individuals who are deaf or hard of hearing at 800-877-8339. In addition, FTA will post answers to questions and requests for clarifications on FTA's website at 
                    <E T="03">https://www.transit.dot.gov/funding/grants/low-no-and-buses-and-bus-facilities-faqs.</E>
                     To ensure applicants receive accurate information about eligibility or the program, applicants are encouraged to contact FTA with questions directly, rather than through intermediaries or third parties.  
                </P>
                <P>
                    For issues with 
                    <E T="03">GRANTS.GOV</E>
                    , please contact 
                    <E T="03">GRANTS.GOV</E>
                     by phone at 1-800-518-4726 or by email at 
                    <E T="03">support@grants.gov.</E>
                     Contact information for FTA's regional offices can be found on FTA's website at 
                    <E T="03">https://www.transit.dot.gov/about/regional-offices/regional-offices.</E>
                </P>
                <HD SOURCE="HD1">H. Other Information</HD>
                <P>
                    User-friendly information and resources regarding DOT's discretionary grant programs relevant to rural applicants can be found on the Rural Opportunities to Use Transportation for Economic Success (ROUTES) website at 
                    <E T="03">https://www.transportation.gov/rural.</E>
                </P>
                <P>This program is not subject to Executive Order 12372, “Intergovernmental Review of Federal Programs.”</P>
                <P>All information submitted as part of or in support of any application shall use publicly available data or data that can be made public and methodologies that are accepted by industry practice and standards, to the extent possible. If an applicant submits information the applicant considers to be a trade secret or confidential commercial or financial information, the applicant must provide that information in a separate document, which the applicant may reference from the application narrative or other portions of the application. For the separate document containing confidential information, the applicant must do the following: (1) state on the cover of that document that it “Contains Confidential Business Information (CBI);” (2) mark each page that contains confidential information with “CBI;” (3) highlight or otherwise denote the confidential content on each page; and (4) at the end of the document, explain how disclosure of the confidential information would cause substantial competitive harm. FTA will protect confidential information complying with these requirements to the extent required under applicable law. If FTA receives a Freedom of Information Act (FOIA) request for the information that the applicant has marked in accordance with this section, FTA will follow the procedures described in DOT's FOIA regulations at 49 CFR 7.29. Only information that is in the separate document, marked in accordance with this section, and ultimately determined to be confidential will be exempt from disclosure under FOIA.</P>
                <SIG>
                    <NAME>Veronica Vanterpool,</NAME>
                    <TITLE>Deputy Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02246 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-57-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Office of Foreign Assets Control</SUBAGY>
                <SUBJECT>Notice of OFAC Sanctions Actions</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Foreign Assets Control, Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) is publishing the names of one or more persons that have been placed on OFAC's Specially Designated Nationals and Blocked Persons List (SDN List) based on OFAC's determination that one or more applicable legal criteria were satisfied. All property and interests in property subject to U.S. jurisdiction of these persons are blocked, and U.S. persons are generally prohibited from engaging in transactions with them.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        See 
                        <E T="02">Supplementary Information</E>
                         section for applicable date(s).
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>OFAC: Associate Director for Global Targeting, tel.: 202-622-2420; Assistant Director for Licensing, tel.: 202-622-2480; Assistant Director for Regulatory Affairs, tel.: 202-622-4855; or Assistant Director for Sanctions Compliance &amp; Evaluation, tel.: 202-622-2490.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Electronic Availability</HD>
                <P>
                    The SDN List and additional information concerning OFAC sanctions programs are available on OFAC's website (
                    <E T="03">https://www.treasury.gov/ofac</E>
                    ).
                    <PRTPAGE P="8754"/>
                </P>
                <HD SOURCE="HD1">Notice of OFAC Actions</HD>
                <HD SOURCE="HD1">Blocking of Property and Interests in Property Pursuant to E.O. 14014</HD>
                <P>On January 31, 2024, OFAC determined that the property and interests in property subject to U.S. jurisdiction of the following persons are blocked under the relevant sanctions authority listed below.</P>
                <HD SOURCE="HD1">Individuals</HD>
                <EXTRACT>
                    <P>1. ZAW, Thein Win, Burma; DOB 02 Feb 1963; POB Twantay, Burma; nationality Burma; Gender Male; Passport MG551721 (Burma) expires 26 Sep 2027; National ID No. 12/LAMANAN133128 (Burma) (individual) [BURMA-EO14014] (Linked To: SHWE BYAIN PHYU GROUP OF COMPANIES).</P>
                    <P>Designated pursuant to section 1(a)(iii)(D) of Executive Order 14014 of February 10, 2021, “Blocking Property With Respect to the Situation in Burma”, 86 FR 9429 (“E.O. 14014”) for being or having been a leader or official of Shwe Byain Phyu Group Of Companies, an entity whose property and interests in property are blocked pursuant to this order as a result of activities related to the leader's or official's tenure.</P>
                    <P>2. MIN, Tin Latt, Burma; DOB 15 Jun 1968; nationality Burma; Gender Female; National ID No. 5/MAYANAN012759 (Burma) (individual) [BURMA-EO14014] (Linked To: ZAW, Thein Win).</P>
                    <P>Designated pursuant to section 1(a)(v) of E.O. 14014 for being a spouse or adult child of Thein Win Zaw, a person whose property and interests in property are blocked pursuant to this order.</P>
                    <P>3. KYAW, Win Paing, Burma; DOB 29 May 1996; nationality Burma; Gender Male; National ID No. 12/LAMANAN151183 (Burma) (individual) [BURMA-EO14014] (Linked To: ZAW, Thein Win).</P>
                    <P>Designated pursuant to section 1(a)(v) of E.O. 14014 for being a spouse or adult child of Thein Win Zaw, a person whose property and interests in property are blocked pursuant to this order.</P>
                    <P>4. HTET, Theint Win, Burma; DOB 21 May 1999; nationality Burma; Gender Female; National ID No. 12/LAMANAN155055 (Burma) (individual) [BURMA-EO14014] (Linked To: ZAW, Thein Win).</P>
                    <P>Designated pursuant to section 1(a)(v) of E.O. 14014 for being a spouse or adult child of Thein Win Zaw, a person whose property and interests in property are blocked pursuant to this order.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Entities</HD>
                <EXTRACT>
                    <P>1. SHWE BYAIN PHYU GROUP OF COMPANIES (a.k.a. SHWE BYAING PHYU GROUP), No. 16 Shwe Taung Kyar Road, 2 Ward Shwe Tuang Kyar, Bahan Township, Yangon 11201, Burma; Organization Established Date 1996; Organization Type: Activities of holding companies [BURMA-EO14014] (Linked To: MYANMA ECONOMIC HOLDINGS PUBLIC COMPANY LIMITED).</P>
                    <P>Designated pursuant to section 1(a)(vi) of E.O. 14014 for having materially assisted, sponsored, or provided financial, material, or technological support for, or goods or services to or in support of Myanma Economic Holdings Public Company Limited, a person whose property and interests in property are blocked pursuant to this order.</P>
                    <P>2. MYANMA FIVE STAR LINE COMPANY LIMITED (a.k.a. MYANMA FIVE STAR LINE; a.k.a. MYANMA FIVE STAR SHIPPING COMPANY; a.k.a. MYANMAR FIVE STAR LINE; a.k.a. “FIVE STAR SHIPPING COMPANY”; a.k.a. “FIVE STAR SHIPPING LINE”; a.k.a. “MFSL”), Burma; Organization Established Date 25 Jun 2010; Organization Type: Sea and coastal freight water transport; Registration Number 107184368 (Burma) [BURMA-EO14014] (Linked To: MYANMA ECONOMIC HOLDINGS PUBLIC COMPANY LIMITED).</P>
                    <P>Designated pursuant to section 1(a)(v) of E.O. 14014 for being owned or controlled by, or having acted or purported to act for or on behalf of, directly or indirectly, Myanma Economic Holdings Public Company Limited, a person whose property and interests in property are blocked pursuant to this order.</P>
                </EXTRACT>
                <P>
                    <E T="03">Authority:</E>
                     E.O. 14014, 86 FR 9429.
                </P>
                <SIG>
                    <DATED>Dated: January 31, 2024.</DATED>
                    <NAME>Bradley T. Smith,</NAME>
                    <TITLE>Director, Office of Foreign Assets Control, U.S. Department of the Treasury.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02240 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4810-AL-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Internal Revenue Service</SUBAGY>
                <SUBJECT>Proposed Collection; Comment Request Relating to Pre-Approved Plans Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Internal Revenue Service (IRS), Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Internal Revenue Service, as part of its continuing effort to reduce paperwork and respondent burden, invites the general public and other Federal agencies to take this opportunity to comment on continuing information collections, as required by the Paperwork Reduction Act of 1995. The IRS is soliciting comments concerning pre-approved plans program.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments should be received on or before April 8, 2024 to be assured of consideration.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Direct all written comments to Andres Garcia, Internal Revenue Service, Room 6526, 1111 Constitution Avenue NW, Washington, DC 20224, or by email to 
                        <E T="03">pra.comments@irs.gov</E>
                        . Include OMB control number 1545-1674 or Pre-Approved Plans Program.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Requests for additional information or copies of the revenue procedures should be directed to Kerry Dennis at (202) 317-5751, or at Internal Revenue Service, Room 6526, 1111 Constitution Avenue NW, Washington, DC 20224, or through the internet, at 
                        <E T="03">Kerry.L.Dennis@irs.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title:</E>
                     Pre-Approved Plans Program.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     1545-1674.
                </P>
                <P>
                    <E T="03">Revenue Procedure:</E>
                     2023-37
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Revenue Procedure 2023-37, and its successors, set forth the procedures of the IRS for issuing opinion letters confirming that the form of a provider's plan satisfies the qualification requirements under the Internal Revenue Code. The OMB approval for 1545-1674 is only covering the third-party disclosures and recordkeeping requirements.
                </P>
                <P>
                    <E T="03">Current Actions:</E>
                     There are no changes being made to the revenue procedure or burden at this time.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profit organizations, not-for-profit institutions, farms, and state, local, or tribal governments.
                </P>
                <FP SOURCE="FP-1">Revenue Procedure 2023-07, Section 9.02(8) and 9.06(6)</FP>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     350,356.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     1 hour.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden Hours:</E>
                     350,356 hours.
                </P>
                <FP SOURCE="FP-1">Revenue Procedure 2023-07, Sections 6.04, 13.01 and 23</FP>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     1,556.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     160 hours.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden Hours:</E>
                     248,960 hours.
                </P>
                <FP SOURCE="FP-1">Total Burden Estimates</FP>
                <P>
                    <E T="03">Estimated Total Respondents:</E>
                     351,912.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     599,316 hours.
                </P>
                <P>The following paragraph applies to all the collections of information covered by this notice.</P>
                <P>An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless the collection of information displays a valid OMB control number. Books or records relating to a collection of information must be retained if their contents may become material in the administration of any internal revenue law. Generally, tax returns and tax return information are confidential, as required by 26 U.S.C. 6103.</P>
                <P>
                    <E T="03">Request for Comments:</E>
                     Comments submitted in response to this notice will 
                    <PRTPAGE P="8755"/>
                    be summarized and/or included in the request for OMB approval. All comments will become a matter of public record. Comments are invited on: (a) whether the collection of information is necessary for the proper performance of the functions of the agency, including whether the information shall have practical utility; (b) the accuracy of the agency's estimate of the burden of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information to be collected; (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology; and (e) estimates of capital or start-up costs and costs of operation, maintenance, and purchase of services to provide information.
                </P>
                <SIG>
                    <DATED>Approved: February 5, 2024.</DATED>
                    <NAME>Kerry L. Dennis,</NAME>
                    <TITLE>Tax Analyst.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02574 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4830-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Internal Revenue Service</SUBAGY>
                <SUBJECT>Proposed Collection; Comment Request for Form 13803</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Internal Revenue Service (IRS), Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Internal Revenue Service (IRS), as part of its continuing effort to reduce paperwork and respondent burden, invites the general public and other Federal agencies to take this opportunity to comment on information collections, as required by the Paperwork Reduction Act of 1995. The IRS is soliciting comments concerning Application to Participate in the Income Verification Express Service (IVES) Program For Mortgage Services Only.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments should be received on or before April 8, 2024 to be assured of consideration.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Direct all written comments to Andres Garcia, Internal Revenue Service, Room 6526, 1111 Constitution Avenue NW, Washington, DC 20224, or by email to 
                        <E T="03">pra.comments@irs.gov</E>
                        . Include “OMB Number 1545-2032-Application to Participate in the Income Verification Express Service (IVES) Program For Mortgage Services Only” in the subject line of the message.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Requests for additional information or copies of this collection should be directed to Martha R. Brinson, at (202)317-5753, or at Internal Revenue Service, Room 6526, 1111 Constitution Avenue NW, Washington, DC 20224, or through the internet at 
                        <E T="03">Martha.R.Brinson@irs.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title:</E>
                     Application to Participate in the Income Verification Express Service (IVES) Program For Mortgage Services Only.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     1545-2032.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     13803.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Application to Participate in the Income Verification Express Service (IVES) Program (For Mortgage Service Only), is used to submit the required information necessary to complete the e-services enrollment process for IVES users and to identify delegates receiving transcripts on behalf of the principle account user.
                </P>
                <HD SOURCE="HD1">Current Actions</HD>
                <P>(1) “For Mortgages Service Only” was added to the Title.</P>
                <P>(2) The checkbox for “Government Agency” was removed from line 2.</P>
                <P>(3) Verbiage was changed in line 3 to “By checking this box, I acknowledge the purpose of the IVES program is to secure third party tax data needed for a mortgage loan on residential or commercial real property (real estate).” Instructions were also added for line 3.</P>
                <P>All other checkboxes were removed from line 3, except “Mortgage Services”.</P>
                <P>
                    <E T="03">Type of Review:</E>
                     Revision of a currently approved collection.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Businesses and other for-profit organizations.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     400.
                </P>
                <P>
                    <E T="03">Estimated Time per Respondent:</E>
                     30 mins.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     100.
                </P>
                <P>The following paragraph applies to all of the collections of information covered by this notice:</P>
                <P>An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless the collection of information displays a valid OMB control number.</P>
                <P>Books or records relating to a collection of information must be retained as long as their contents may become material in the administration of any internal revenue law. Generally, tax returns and tax return information are confidential, as required by 26 U.S.C. 6103.</P>
                <P>
                    <E T="03">Request for Comments:</E>
                     Comments submitted in response to this notice will be summarized and/or included in the request for OMB approval. Comments will be of public record. Comments are invited on: (a) whether the collection of information is necessary for the proper performance of the functions of the agency, including whether the information has practical utility; (b) the accuracy of the agency's estimate of the burden of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information to be collected; (d) ways to minimize the burden of the collection of information on or other forms of information technology; and (e) estimates of capital or start-up costs and costs of operation, maintenance, and purchase of services to provide information.
                </P>
                <SIG>
                    <DATED>Approved: February 1, 2024.</DATED>
                    <NAME>Martha R. Brinson,</NAME>
                    <TITLE>Tax Analyst.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-02575 Filed 2-7-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4830-01-P</BILCOD>
        </NOTICE>
    </NOTICES>
    <VOL>89</VOL>
    <NO>27</NO>
    <DATE>Thursday, February 8, 2024</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="8757"/>
            <PARTNO>Part II</PARTNO>
            <AGENCY TYPE="P">Department of Health and Human Services</AGENCY>
            <SUBAGY> Centers for Medicare &amp; Medicaid Services</SUBAGY>
            <HRULE/>
            <CFR>42 Parts 422, 431, 435, et al.</CFR>
            <CFR>45 Part 156</CFR>
            <TITLE>Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program; Final Rule</TITLE>
        </PTITLE>
        <RULES>
            <RULE>
                <PREAMB>
                    <PRTPAGE P="8758"/>
                    <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                    <SUBAGY>Centers for Medicare &amp; Medicaid Services</SUBAGY>
                    <CFR>42 CFR Parts 422, 431, 435, 438, 440, and 457</CFR>
                    <SUBAGY>Office of the Secretary</SUBAGY>
                    <CFR>45 CFR Part 156</CFR>
                    <DEPDOC>[CMS-0057-F]</DEPDOC>
                    <RIN>RIN 0938-AU87</RIN>
                    <SUBJECT>Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program</SUBJECT>
                    <AGY>
                        <HD SOURCE="HED">AGENCY:</HD>
                        <P>Centers for Medicare &amp; Medicaid Services (CMS), Department of Health and Human Services (HHS).</P>
                    </AGY>
                    <ACT>
                        <HD SOURCE="HED">ACTION:</HD>
                        <P>Final rule.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>This final rule will improve the electronic exchange of health care data and streamline processes related to prior authorization through new requirements for Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). This final rule will also add new measures for eligible hospitals and critical access hospitals (CAHs) to report under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians to report under the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). These policies, taken together, will reduce overall payer and provider burden and improve patient access to health information while continuing CMS's drive toward interoperability in the health care market.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P>These regulations are effective on April 8, 2024.</P>
                    </EFFDATE>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P/>
                        <P>Alexandra Mugge, (410) 786-4457, for general questions related to any of the policies in this final rule, or questions related to CMS interoperability initiatives.</P>
                        <P>Lorraine Doo, (443) 615-1309, for issues related to the prior authorization process policies, or the Prior Authorization Application Programming Interface (API).</P>
                        <P>Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measures for the MIPS Promoting Interoperability performance category and Medicare Promoting Interoperability Program, or any of the API standards and implementation guides (IGs) included in this final rule.</P>
                        <P>David Koppel, (303) 844-2883, for issues related to the data exchange policies generally, Patient Access API policies, or patient privacy.</P>
                        <P>Scott Weinberg, (410) 786-6017, for issues related to the Provider Access API policies.</P>
                        <P>Amy Gentile, (410) 786-3499, for issues related to Medicaid managed care.</P>
                        <P>Kirsten Jensen, (410) 786-8146, for issues related to Medicaid FFS.</P>
                        <P>Joshua Bougie, (410) 786-8117, for issues related to CHIP.</P>
                        <P>Natalie Albright, (410) 786-1671, for issues related to MA organizations.</P>
                        <P>Carolyn Kraemer, (301) 492-4197, for issues related to QHPs.</P>
                        <P>Elizabeth Holland, (410) 786-1309, for issues related to MIPS and the Medicare Promoting Interoperability Program.</P>
                        <P>Russell Hendel, (410) 786-0329, for issues related to the Collection of Information and Regulatory Impact Analysis.</P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P/>
                    <HD SOURCE="HD1">Table of Contents</HD>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Background and Summary of Provisions</FP>
                        <FP SOURCE="FP1-2">A. Purpose and Background</FP>
                        <FP SOURCE="FP1-2">B. Summary of Major Provisions</FP>
                        <FP SOURCE="FP1-2">C. Specific Terms Used in This Final Rule</FP>
                        <FP SOURCE="FP1-2">D. Global Comments</FP>
                        <FP SOURCE="FP-2">II. Provisions of the Proposed Rule</FP>
                        <FP SOURCE="FP1-2">A. Patient Access API</FP>
                        <FP SOURCE="FP1-2">B. Provider Access API</FP>
                        <FP SOURCE="FP1-2">C. Payer-to-Payer API</FP>
                        <FP SOURCE="FP1-2">D. Prior Authorization API and Improving Prior Authorization Processes</FP>
                        <FP SOURCE="FP1-2">E. Extensions, Exemptions, and Exceptions; Federal Matching Funds for Medicaid and CHIP</FP>
                        <FP SOURCE="FP1-2">F. Electronic Prior Authorization Measures for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program</FP>
                        <FP SOURCE="FP1-2">G. Interoperability Standards for APIs</FP>
                        <FP SOURCE="FP-2">III. Collection of Information Requirements</FP>
                        <FP SOURCE="FP-2">IV. Regulatory Impact Analysis</FP>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Background, Summary of Provisions, and Terms</HD>
                    <HD SOURCE="HD2">A. Purpose and Background</HD>
                    <P>
                        In the December 13, 2022 
                        <E T="04">Federal Register</E>
                         (87 FR 76238), we issued the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program” proposed rule (CMS Interoperability and Prior Authorization proposed rule), in which we proposed new requirements for MA, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs (collectively “impacted payers”) to improve the electronic exchange of health care information and streamline prior authorization for medical items and services. The proposed rule also included proposals for new electronic prior authorization measures for MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the Promoting Interoperability performance category of the MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program.
                    </P>
                    <P>This rule also builds upon the policies established in the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA 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 (85 FR 25510, May 1, 2020) (hereinafter referred to as the “CMS Interoperability and Patient Access final rule”).</P>
                    <P>
                        We received nearly 900 timely pieces of correspondence containing comments on the CMS Interoperability and Prior Authorization proposed rule. Some public comments were outside of the scope of the proposed rule and those out-of-scope comments are not addressed in this final rule. Summaries 
                        <PRTPAGE P="8759"/>
                        of the public comments that are within the scope of the proposed rule and our responses to those public comments are addressed in the various sections of this final rule under the appropriate heading. However, in this section we address certain comments that pertain across policies or to the rule overall.
                    </P>
                    <P>In this final rule, we are finalizing our proposals with modifications in response to commenter feedback. Taken together, these final policies will help to increase health information data exchange, streamline prior authorization process policies, and help to address a significant source of provider burden and burnout to ultimately improve patients' access to timely care.</P>
                    <HD SOURCE="HD2">B. Summary of Major Provisions</HD>
                    <P>In the CMS Interoperability and Patient Access final rule, we required impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a standards-based Patient Access API. The Patient Access API must allow patients, through the health apps of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, provider remittances, and patient cost-sharing pertaining to such claims, if maintained by the impacted payer (85 FR 25558). In this final rule, we are finalizing our proposal to require that impacted payers include information about certain prior authorizations in the data that are available through the Patient Access API. For those changes to the Patient Access API, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). In addition, starting January 1, 2026, we are requiring impacted payers to annually report to CMS certain metrics about patient data requests made via the Patient Access API. We are also finalizing our proposal to directly reference the content standard at 45 CFR 170.213, so that the data content requirement is automatically updated as HHS's Office of the National Coordinator for Health Information Technology (ONC) adopts new versions. As of this final rule's publication, the content standards adopted at 45 CFR 170.213 are USCDI v1, which will expire on January 1, 2026, and USCDI v3.</P>
                    <P>To improve coordination of care across the care continuum and movement toward value-based care, we are finalizing our proposal to require impacted payers to implement and maintain a Provider Access API that is consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), including the Health Level Seven (HL7®) International Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 standard. Providers can use that API to access current patient data from payers, including adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and prior authorization information. For the Provider Access API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027 for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for QHP issuers on the FFEs).</P>
                    <P>We are finalizing, with modifications, our proposal to require impacted payers to implement and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers to ensure continued access to their health data and support continuity of care between payers. Specifically, the payer to payer data exchange will include adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about the patient's prior authorizations. Impacted payers will be required to request data from a patient's previous payer, with the patient's permission, no later than 1 week from the start of coverage or at the patient's request. Impacted payers will then be required to integrate any data they receive in response to that request into the patient's record, which could facilitate care continuity as patients move between payers. We are finalizing a policy that payers will be required to exchange five years of patient data, as opposed to the entire patient health record. Five years of data are sufficient to support care continuity and continuation of prior authorizations as necessary, as well as maintaining patient access to their most recent data without significant burden to payers. In addition, if a patient has two or more concurrent impacted payers, the impacted payers will be required to exchange the patient's data at least quarterly, to ensure that all impacted payers have a more complete patient record. For the Payer-to-Payer API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).</P>
                    <P>To improve the patient experience and access to care, we are also finalizing several new requirements for prior authorization processes that will reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are requiring impacted payers to implement and maintain a Prior Authorization API. In the proposed rule, we used the term “Prior Authorization Requirements, Documentation, and Decision API (PARDD API).” For simplicity, we are finalizing the name of that API as simply the “Prior Authorization API.” This name change alone does not indicate any changes to the requirements or standards that we proposed.</P>
                    <P>Providers can use the Prior Authorization API to determine whether a specific payer requires prior authorization for a certain item or service, thereby easing one of the major points of administrative burden in the existing prior authorization process. The Prior Authorization API will also allow providers to query the payer's prior authorization documentation requirements directly from the provider's system, which could facilitate the automated compilation of necessary information to submit a prior authorization request. For the Prior Authorization API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).</P>
                    <P>
                        We are also finalizing our proposals to establish certain requirements for the prior authorization process, regardless of whether the payer receives the prior authorization request through the Prior Authorization API. We are requiring that impacted payers send notices to providers when they make a prior authorization decision, including a 
                        <PRTPAGE P="8760"/>
                        specific reason for denial when they deny a prior authorization request. We are also finalizing our proposal to require impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. Finally, we are requiring all impacted payers to publicly report certain metrics about their prior authorization processes, which will enhance transparency. For these prior authorization process policies, we are finalizing compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).
                    </P>
                    <P>We are finalizing, with modifications, our proposal for new electronic prior authorization measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote Prior Authorization API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are adding new measures titled “Electronic Prior Authorization” under the Health Information Exchange (HIE) objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year (CY) 2027 performance period/2029 MIPS payment year and CY 2027 electronic health record (EHR) reporting period, respectively. As detailed in section II.F. of this final rule, we are finalizing a modification to our proposal for the Electronic Prior Authorization measure that will require a MIPS eligible clinician, eligible hospital, or CAH to report a yes/no attestation or (if applicable) an exclusion, rather than a numerator and denominator.</P>
                    <P>We are additionally finalizing our proposals, with modifications, for more specificity as to which of the required standards at 45 CFR 170.215 are applicable to each API. Impacted payers will only be required to use the specifications that CMS has identified as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. Since the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has published the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) final rule (January 9, 2024; 89 FR 1192) (hereinafter referred to as the HTI-1 final rule), which reorganized the structure of 45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification. The standards we are finalizing in this rule, including updated citations are as follows:</P>
                    <P>• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR).</P>
                    <P>• HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i) (US Core IG).</P>
                    <P>• HL7® SMART Application Launch Framework IG Release 1.0.0 which expires on January 1, 2026, at 45 CFR 170.215(c)(1) (SMART App Launch IG).</P>
                    <P>• FHIR® Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1) (Bulk Data Access IG).</P>
                    <P>• OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core).</P>
                    <P>We refer readers to the HTI-1 final rule for further information (89 FR 1192). More detail about the required standards can be found in section II.G. and Table H3. We are also strongly recommending that payers use specific IGs to supplement the required standards at 45 CFR 170.215. Additionally, we are finalizing our proposal to allow payers to voluntarily use updated versions of the standards, specifications, or IGs for each of these APIs prior to the adoption of updated versions in regulation, subject to certain conditions and provided the updated standard does not disrupt an end user's ability to access the data available through the API. We are also finalizing terminology changes related to the Patient Access API (in section II.A.2.d. of this final rule). These policies will take effect on the effective date of the final rule.</P>
                    <P>We are finalizing, as proposed, some clarifications to existing Medicaid beneficiary notice and fair hearing regulations that apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, as we proposed, Medicaid agencies will have to comply with these policies upon the effective date of a final rule.</P>
                    <P>In our proposed rule, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), for all policies that require API development and enhancement. Based on commenter feedback and as noted previously, we are delaying the compliance dates in this final rule for the provisions that require API development and enhancement in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers.</P>
                    <P>We believe this approximately 3-year timeline to recruit and train staff, update, or build the APIs, and update operational procedures will be sufficient to implement these policies, based on comments and public information from some payers and providers regarding similar initiatives already in progress. In addition to the 3-year implementation timeframe, we are finalizing our proposal to give state Medicaid and CHIP FFS programs an opportunity to seek an extension to the compliance dates, or an exemption from meeting certain requirements, in certain circumstances. Additionally, we are finalizing our proposal to provide an exceptions process for QHP issuers on the FFEs. We believe the approximately 3-year timeframe for implementation in the final rule will offer sufficient time for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to determine whether they can timely satisfy the API development and enhancement requirements in this final rule and to prepare the necessary documentation to request an extension, exemption, or exception, as applicable.</P>
                    <P>
                        Executive Order 13985 of January 20, 2021, entitled “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,” set administration policy that the “Federal Government should pursue a comprehensive approach to advancing equity for all.” 
                        <SU>1</SU>
                        <FTREF/>
                         CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and the policies in this final rule are aligned with that Executive order because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology that affect many patient populations. Some patient populations are more negatively affected by existing processes than 
                        <PRTPAGE P="8761"/>
                        others and should realize greater benefits through the improvements these policies will provide. One of the main components of this final rule is our continued support for the individual's ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1</SU>
                             Executive Order 13985, sec. 1, 86 FR 7009 (January 20, 2021).
                        </P>
                    </FTNT>
                    <P>
                        Our goal is to ensure that these proposed policies do not exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies by using secure technologies, such as Open Authorization/Open ID (OAuth) 2.0 and OpenID Connect Core for authentication,
                        <SU>2</SU>
                        <FTREF/>
                         as previously discussed in the CMS Interoperability and Patient Access final rule (85 FR 25520). While we proposed policies that we believed would address some health care inequities, we solicited comments about how to ensure that individuals from all communities and populations can actively benefit from our health care interoperability proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>2</SU>
                             Health Level Seven International. Smart App Launch Implementation Guide, OpenID and Authentication for Smart Apps. Retrieved from 
                            <E T="03">https://hl7.org/fhir/smart-app-launch/.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">C. Specific Terms Used in This Final Rule</HD>
                    <P>Our policies emphasize improving health information exchange and facilitating appropriate and necessary patient, provider, and payer access to information in health records. We also include several policies intended to reduce payer, provider, and patient burden by improving prior authorization processes and helping patients remain at the center of their care. Prior authorization refers to the process through which a health care provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care. Payers establish prior authorization requirements to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and, for some payers, is consistent with standards of care before the item or service is provided. A prior authorization is made up of two parts—a request from a provider and a decision by a payer. We refer to the provider's workflow and associated information and documentation as the “prior authorization request” and the payer's processes and associated information and documentation as the “prior authorization decision.”</P>
                    <P>For purposes of this final rule, references to QHP issuers on the FFEs exclude issuers offering only stand-alone dental plans (SADPs). Likewise, we are also excluding QHP issuers offering only QHPs in the Federally-facilitated Small Business Health Options Program Exchanges (FF-SHOPs) from the provisions of this final rule, as we believe that the standards could be overly burdensome for both SADP and Small Business Health Options Program (SHOP) issuers. We are finalizing an exceptions process for QHP issuers on the FFEs from the API requirements; the grant of an exception is conditioned upon our annual approval of a narrative justification, as further detailed in section II.E. of this final rule. For the purposes of this final rule, FFEs include FFEs in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though patients in those states enroll in coverage through HealthCare.gov. Hence, QHP issuers in SBE-FPs will not be subject to the requirements in this final rule. We encourage SBE-FPs and State-based Exchanges operating their own platforms (SBEs) to consider adopting similar requirements for QHPs on their Exchanges.</P>
                    <P>
                        Throughout this final rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this final rule is a patient who has received or will receive, medical care at some point in their life. In this final rule, we use the term “patient” as an inclusive term. We understand that, historically, we have referred in our regulations to “patients” using the other terms previously noted. However, for the policies herein, we will use additional, specific terms applicable to individuals covered under the health care programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may opt into or out of certain types of information exchange under the policies in this final rule. But when we refer to a patient's medical needs or health records, we do not include the medical needs or health records of the patient's personal representative. Per the Standards for Privacy of Individually Identifiable Health Information (Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule) 
                        <SU>3</SU>
                        <FTREF/>
                         issued under HIPAA (Pub. L. 104-191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance, a “personal representative” is a person authorized under state or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney).
                        <SU>4</SU>
                        <FTREF/>
                         Under the HIPAA Privacy Rule (45 CFR part 164, subpart E), the individual's personal representative generally may exercise the right to access the individual's protected health information (PHI). For many processes described in this final rule, a patient's personal representative could act on a patient's behalf, as permitted by the HIPAA Privacy Rule and other applicable laws.
                    </P>
                    <FTNT>
                        <P>
                            <SU>3</SU>
                             
                            <E T="03">See</E>
                             45 CFR parts 160 and 164, subparts A and E.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             U.S. Department of Health and Human Services. Health Information and Privacy. Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html</E>
                             and 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.</E>
                        </P>
                    </FTNT>
                    <P>We also use terms such as “payer,” “plan,” and “issuer” in this final rule. Certain portions of this final rule are applicable to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. Where certain provisions may not apply to specific plan or provider types, we have identified them separately from the aforementioned categories. We use the term “payer” in the preamble of this final rule as an inclusive term for all these entities and programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this final rule.</P>
                    <P>
                        We use the term “policies that require API enhancement or development” to describe the requirements that involve technical development work to either establish a new API, such as the Provider Access or Payer-to-Payer APIs, or to enhance the functionality of an existing API, such as the addition of 
                        <PRTPAGE P="8762"/>
                        prior authorization data to the Patient Access API. We are finalizing these policies with compliance dates in 2027. As discussed throughout this rule, we are finalizing a modification to our proposal for certain requirements by establishing compliance dates in 2027, rather than in 2026, as we proposed. Specifically, those policies include adding prior authorization information to the Patient Access API, implementing the Provider Access API (including a process for patients to opt out and disseminating educational resources to patients and providers), implementing the Payer-to-Payer API (including processes for gathering previous/concurrent payer information and for patients to opt in, and disseminating educational resources to patients), and implementing the Prior Authorization API. We are not including in the group of “policies that require API enhancement or development” terminology changes for the Patient Access API, reporting Patient Access API metrics, changes to prior authorization processes, reporting prior authorization metrics, Medicaid notice and fair hearings changes, the MIPS and Medicare Promoting Interoperability measures, and updated standards. An explanation of why we are establishing these deadlines for each policy is found in section I.D.2. of this final rule and throughout this rule.
                    </P>
                    <P>We use the term “items and services” when discussing prior authorization in this final rule. Unless otherwise stated, the policies for prior authorization APIs and processes do not apply to drugs of any type, meaning any drugs that could be covered by the impacted payers in this final rule (for example, prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital), because the processes and standards for prior authorization of drugs differ from the other “items and services” included in our final policies. In the CMS Interoperability and Patient Access final rule, we finalized policies that require payers to send claims data related to prescription and other drug claims via a Patient Access API, and we are finalizing certain provisions related to claims data in this final rule. For example, Medicare Advantage Prescription Drug (MA-PD) plans that cover Part A, Part B, and Part D benefits, as well as supplemental benefits, are required to provide access to information about all those covered benefits through the Patient Access API at 42 CFR 422.119(b). Prescription and other drug information is part of a patient's record and giving patients, providers, and payers access to claims data for prescription and other drugs can offer valuable insights into a patient's health care, provide benefits for care coordination, and help avoid potentially harmful drug interactions. We acknowledge that there are existing laws and regulations that may apply to prior authorization of drugs for the impacted payers in this final rule. Thus, while the claims data included in this final rule and existing policies do include prescription and other drug claims, our policies in this final rule related to prior authorization do not include standards or policies for any drugs (as previously described), including covered outpatient drugs under Medicaid, and Medicare Part B or Part D drugs covered by an MA (including an MA-PD) plan.</P>
                    <P>Additionally, we use the terms “provider” and “supplier” as inclusive terms composed of individuals, organizations, and institutions that provide or furnish health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities (SNF), home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS), community-based organizations, as appropriate in the context used. When specifically discussing policies related to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and CAHs.</P>
                    <P>Throughout this final rule, we finalize API provisions in which we refer to the API functionality as a single API, though we acknowledge that payers may implement this functionality by using one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this final rule) as a single API to describe the functionality, payers may achieve the same functionality with one or multiple APIs, depending on the implementation approach.</P>
                    <P>
                        An API is a set of commands, functions, protocols, or tools published by one software developer (“A”) that enables other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software while maintaining data security and patient privacy (if properly implemented). This is how API technology enables the seamless user experiences, which are familiar in other aspects of patients' daily lives, such as travel and personal finance smartphone apps, which can function without being integrated into the smartphone's operating system. Standardized, secure, transparent, and pro-competitive API technology can provide similar benefits for patients of health care services.
                        <SU>5</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             Office of the National Coordinator for Health Information Technology (n.d.). Application Programming Interfaces. Retrieved from 
                            <E T="03">https://www.healthit.gov/api-education-module/story_html5.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Health Level 7 (HL7®) is the standards development organization (SDO) that develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this final rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at 
                        <E T="03">www.HL7.org.</E>
                        <SU>6</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             Health Level Seven International (2023). Guide to Using HL7 Trademarks. Retrieved from 
                            <E T="03">http://www.hl7.org/legal/trademarks.cfm?ref=nav.</E>
                        </P>
                    </FTNT>
                    <P>Finally, throughout this final rule we discuss the APIs in relation to the programmatic requirements to share data between payers, providers, and patients under specific rules. However, payers could use these APIs to exchange data for myriad purposes, beyond those in this final rule. For instance, a patient could request data outside the scope of this final rule, or program integrity entities could request data from payers (such as under the Inspector General Act of 1978). Nothing in this final rule prevents payers from sharing the requested data via these APIs, if technologically feasible, for appropriate purposes permitted by law. We encourage using these standards-based APIs for purposes beyond our requirements to improve the interoperability of health data, regardless of the use case.</P>
                    <HD SOURCE="HD2">D. Global Comments</HD>
                    <P>
                        CMS received nearly 900 timely pieces of correspondence in response to the CMS Interoperability and Prior Authorization proposed rule. We summarize comments that are globally applicable to the final rule here. In this section, we address comments related to Medicare FFS implementation, the National Directory of Healthcare (NDH), final policy compliance dates, exclusion of drugs from the prior authorization policies in this final rule, the payers impacted by this final rule, the withdrawal of the “Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care 
                        <PRTPAGE P="8763"/>
                        Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges; Health Information Technology Standards and Implementation Specifications” proposed rule (December 2020 CMS Interoperability proposed rule) (87 FR 76239), and compliance and enforcement.
                    </P>
                    <HD SOURCE="HD3">1. Medicare Fee-for-Service Implementation of Final Policies</HD>
                    <P>Although these requirements do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies in this final rule, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on data exchange, including through the Provider Access, Payer-to-Payer, and Prior Authorization APIs, and therefore we solicited comments on how these proposals could apply to Medicare FFS. We also encouraged other payers not directly impacted by this final rule to consider the policies in this final rule for voluntary adoption to reduce burden and support greater interoperability.</P>
                    <P>A significant number of commenters expressed support for our intention to ensure that Medicare FFS will comply with the requirements of this final rule by the compliance dates we are establishing. We did not make any policy proposals regarding this effort, but we are considering comments as we plan our roadmap for implementation.</P>
                    <HD SOURCE="HD3">2. Compliance Dates and Enforcement</HD>
                    <P>For our proposals that require API enhancement or development, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs) (87 FR 76289) and indicated that we thought that a 3-year timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient. In the proposed rule we used the term “implementation dates” rather than “compliance dates” as we are using in this final rule. Because payers may implement APIs before the compliance dates, we want to be clear when we are discussing the regulatory deadlines in this final rule. This terminology does not indicate any changes to the substance of any proposals or finalized requirements.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed support for the proposed compliance dates in 2026. A commenter stated that the proposed compliance dates give impacted payers, health information technology (IT) developers, and providers sufficient time to prepare for widespread adoption and utilization. A commenter stated that the feasibility of implementation in 2026 will depend on the complexities of the implementation and the date the final rule is published. Another commenter suggested that CMS provide an implementation timeline with steps to ensure all parties are ready for implementation in 2026. Another commenter wrote that CMS should conduct pilots before the proposed 2026 compliance dates.
                    </P>
                    <P>Multiple commenters recommended that CMS establish a shorter timeframe for the revisions to the Patient Access API and the implementation of the new APIs. Commenters stated that the benefits of our prior authorization proposals are especially necessary and encouraged us to finalize compliance dates as early as possible. A commenter recommended that CMS require MA organizations to implement the requirements within 90 days of publication of this final rule. Another commenter stated that they believe that MA organizations have the revenue and resources to implement the provisions in CY 2024.</P>
                    <P>Payers have indicated that they are already collecting information about how patients are using their Patient Access API, and many submitted comments based on the patient uptake they are witnessing. We did not receive comments that indicated that collecting and reporting these metrics would be a burden on payers.</P>
                    <P>Multiple commenters expressed concern regarding the proposed 2026 compliance dates, for most of the requirements in the rule. Other commenters emphasized that payers would have to begin work on implementation immediately following publication of this final rule to meet all requirements by the 2026 compliance dates. Multiple commenters recommended that CMS delay the compliance dates to 2027 or 2028, citing the feasibility of technology implementation and operational changes.</P>
                    <P>Commenters indicated that state Medicaid and CHIP FFS programs may need more time to implement because they need to secure funding and engage in the state's procurement process. A commenter recommended compliance dates no earlier than January 1, 2027, with state Medicaid and CHIP agencies having the ability to request up to two 1-year extensions following that date. The commenter noted that due to unique funding cycles and procurement requirements, states could require more time than other payers to implement the proposed requirements.</P>
                    <P>Multiple commenters weighed in on the amount of time that payers will need to implement the provisions in the proposed rule. Multiple commenters noted that the proposed requirements for payers to implement four APIs within less than 3 years from publication of the final rule would create a significant burden on payers. A commenter stated that developers will need 12-18 months from the publication of a final rule to design, develop, test, and release updated software. The commenter stated that payers will also need time to implement the updated functionality and train staff to assist patients and other API end users. Another commenter stated that developers would need 18 months per API. A commenter recommended that CMS finalize any policies with at least 24 months of lead time. Another commenter suggested that CMS provide at least 24 to 36 months after the publication of the final rule for payers to comply. Other commenters suggested 3 years between publishing a final rule and the compliance dates. Several commenters recommended that CMS consider a staggered implementation approach for the API requirements.</P>
                    <P>Commenters indicated that, of our proposals, the technical development and enhancement of the required APIs would necessitate a longer implementation period than the prior authorization process improvements.</P>
                    <P>
                        <E T="03">Response:</E>
                         Having taken into consideration comments about the implementation timeline generally and about each of the policies specifically, we are finalizing our policies that require API development or enhancement with compliance dates in 2027. Specifically, MA organizations and state Medicaid and CHIP FFS programs must comply with those policies by January 1, 2027; Medicaid managed care plans and CHIP managed care entities must comply beginning with the first rating period that begins on or after January 1, 2027; and QHPs in FFEs must comply by the first plan year beginning on or after January 1, 2027. For simplicity, throughout this rule we generally refer to these compliance dates as “in 2027” for the various payers. However, we are finalizing some of our other policies with the proposed 2026 compliance dates, as noted in the Summary of Major Provisions.
                        <PRTPAGE P="8764"/>
                    </P>
                    <P>Specifically, we are finalizing 2026 compliance dates for the requirements that impacted payers report Patient Access API metrics to CMS, make standard and expedited prior authorization decisions within specific timeframes, send notices to providers, including a specific denial reason for denied prior authorizations, and publicly report prior authorization metrics on their websites. While these policies require a certain level of development and implementation effort, they are not as technically challenging as implementing the APIs. Thus, we believe a nearly 2-year implementation timeframe is sufficient and will allow payers to prioritize them for an earlier deadline.</P>
                    <P>Because impacted payers should already have Patient Access APIs implemented based on requirements finalized in the CMS Interoperability and Patient Access final rule, reporting on usage of that API should not be a significant burden to payers. We proposed to gather those data to understand how the Patient Access API is being adopted across the industry. We do not believe there is any benefit to delaying this reporting requirement, as we need these data to help inform future policies.</P>
                    <P>Importantly, the prior authorization policies we are finalizing with 2026 compliance dates should reduce the burden of prior authorization processes, even before the 2027 compliance dates for the API development and enhancement policies. Requiring impacted payers to send provider notices, including a specific denial reason, respond within specific timeframes, and report prior authorization metrics will apply regardless of how the payer received the prior authorization request, and are not dependent on the API. Therefore, we do not believe there is a reason to tie those requirements to the API compliance dates. Delaying the changes to prior authorization timeframes and procedures would only delay the benefits of those new policies.</P>
                    <P>However, we are sensitive to the implementation burdens on payers, particularly for the final policies that require API development or enhancement. We understand that payers need time to design, develop, test, and implement major system changes to implement the new Provider Access, Payer-to-Payer, and Prior Authorization APIs. We considered finalizing staggered API compliance dates between 2026 and 2027, as some commenters suggested, but concluded that we are not in the best position to prioritize and understand what work can feasibly be completed by 2026 and what scope is better in a second phase for 2027. Instead, we are delaying the compliance dates for the three new APIs and modifications to the Patient Access API by 1 year from the proposed compliance dates to allow payers time to sufficiently plan, develop, test, and implement this technology. After considering the comments we received, we agree with the volume of commenters that indicated that more than 2 years is necessary from the publication of the final rule for payers to meet the new API requirements. In consideration of the schedule for this final rule's publication, we are finalizing compliance dates in 2027, for the new Provider Access, Payer-to-Payer, and Prior Authorization API requirements in this final rule. Throughout the final rule, we specify the exact regulatory citations that are being modified from our proposed rule to reflect the finalized compliance dates for each payer.</P>
                    <P>We are addressing concerns specific to state Medicaid and CHIP programs with the availability of an extension for Medicaid and CHIP agencies, under which states could seek to delay implementation until 2028, as discussed in section II.E. of this final rule. In that section, we also discuss the possibility of states receiving enhanced Federal Financial Participation (FFP) for expenditures related to implementing these requirements.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed concern regarding the lack of discussion in the proposed rule for mechanisms to ensure compliance with the provisions of the rule once finalized. Multiple commenters recommended that CMS clearly outline how it will conduct oversight and enforcement of the requirements in the rule and commenters recommended that CMS outline a process for formal oversight, audit, and enforcement, including financial penalties and other consequences to promote accountability. A commenter questioned the enforcement and oversight activities for the CMS Interoperability and Patient Access final rule (CMS-9115-F). Another commenter highlighted the lack of penalties for non-compliance with the Provider Directory API. Other commenters recommended that CMS develop a structured process for the public to report non-compliance. Multiple commenters recommended that CMS closely monitor payer compliance and impose civil monetary penalties on payers that are non-compliant.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As explained in the proposed rule and the CMS Interoperability and Patient Access final rule, each CMS program oversees compliance under existing program authorities and responsibilities for the different types of payers impacted by these API requirements (for example, MA organizations, Medicaid programs, etc.). Oversight and compliance procedures and processes vary among these CMS programs and CMS may choose from an array of possible enforcement actions, based on a payer's status in the program, previous compliance actions, and corrective action plans. Therefore, we do not address specific potential compliance and enforcement actions across impacted payers in this final rule, although we do discuss categories of enforcement actions that CMS could consider for various payers in the discussion later in this section. Patients and providers may submit an inquiry or complaint to the appropriate authority, depending on their coverage.
                    </P>
                    <P>
                        For MA organizations, because these are program requirements, depending on the extent of the violation, CMS may take compliance actions from warning letters or requiring a corrective action plan, to enforcement actions including sanctions, civil money penalties and other measures specified at 42 CFR part 422, subpart O. If an MA enrollee believes a plan is not fulfilling its responsibilities with respect to the API requirements, they have a right to file a grievance with a plan under the procedures at 42 CFR 422.564. Individuals may also submit complaints about their MA plans to 1-800-MEDICARE and the online complaint system at 
                        <E T="03">https://www.medicare.gov/my/medicare-complaint.</E>
                         The State Health Insurance Assistance Programs (SHIP) are available to help Medicare beneficiaries, including with filing complaints.
                    </P>
                    <P>When states use enhanced funding for expenditures related to system modifications or enhancements, CMS's enforcement is based upon 45 CFR 95.612 (Disallowance of FFP) and the methodology described in the Centers for Medicaid and CHIP Services (CMCS) Informational Bulletin (CIB), “Medicaid Enterprise Systems Compliance and Reapproval Process for State Systems with Operational Costs Claimed at the 75 Percent Federal Match Rate,” published May 24, 2023. If a state is not compliant with the requirements included in this final rule, the appropriate program policy team will address compliance enforcement.</P>
                    <P>
                        States are obligated by 42 CFR 438.66(b) and (c) to have a monitoring system for all of their managed care programs, including the performance of 
                        <PRTPAGE P="8765"/>
                        each managed care plan, to ensure that all managed care plans are fulfilling their contractual obligations. States report the results of their monitoring activities in an annual Managed Care Program Annual Report, in accordance with 42 CFR 438.66(e). Further, per 42 CFR 438.3(a), CMS must review and approve all managed care plan contracts. Should information in a state's Managed Care Program Annual Report or contract indicate a need for improvement or correction, CMS would work with the state to ensure that the issue is remedied. Patients or providers with concerns regarding Medicaid or CHIP FFS should contact their state Medicaid or CHIP agency. Patients and providers can contact 
                        <E T="03">Medicaid.gov@cms.hhs.gov</E>
                         if the state agency is not responsive.
                    </P>
                    <P>For any concerns related to compliance by Medicaid managed care plans and CHIP managed care entities, enrollees and providers should first contact their managed care plan or managed care entity. Enrollees or providers can contact the state Medicaid or CHIP agency to report issues that they cannot resolve by working with the managed care plan or entity directly.</P>
                    <P>Consistent with the authority under 45 CFR 156.715, the Center for Consumer Information and Insurance Oversight (CCIIO) performs compliance reviews of issuers in the FFEs. In addition, 45 CFR 156.800 through 156.815 provides for additional enforcement remedies including Civil Money Penalties (CMPs) and Notices of Non-Compliance (NONCs) as well as paths to QHP issuer Suppression and Decertification. If enrollees in a QHP on the FFEs or their providers have concerns about an issuer's interoperability implementation, they should first contact their health plan with questions. For issues that they cannot resolve by working directly with the plan, enrollees and providers can contact the Marketplace Call Center at 1-800-318-2596 (TTY: 1-855-889-4325).</P>
                    <P>
                        CMS manages compliance with the HIPAA administrative transaction standards under the authority of the administrative simplification rules. Complaints about non-compliance can be submitted to CMS at 
                        <E T="03">https://asett.cms.gov/ASETT_HomePage.</E>
                    </P>
                    <HD SOURCE="HD3">3. Exclusion of Drugs</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we stated that we were excluding drugs from the Prior Authorization API and proposed process requirements for prior authorizations because the standards and processes for issuing prior authorizations for drugs differ from those that apply to medical items and services.</P>
                    <P>Under state Medicaid programs and the MA program, there are similar timing requirements for prior authorizations for coverage of drugs. MA plans are required to respond to expedited requests for Part B drugs within 24 hours (42 CFR 422.572) and to non-expedited requests as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receipt of the request (42 CFR 422.568). Further, MA-PD plans that cover Part A, B, and D benefits must comply with similar timelines in responding to prior authorization requests for Part D prescription drugs (42 CFR 423.568, 423.572). Similarly, under Medicaid (both FFS and managed care), if a state requires prior authorizations for covered outpatient drugs, a response must be provided within 24 hours of the request for prior authorization (see section 1927(d)(5) of the Social Security Act (the Act) and 42 CFR 438.3(s)(6)). We acknowledge that other drugs do not meet the definition of “covered outpatient drugs,” including cancer drugs, special treatments, and other important medications, and thus are not subject to these prior authorization timeline requirements.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A plethora of commenters provided input and requested that CMS reconsider the proposal to exclude drugs and instead include drugs in the prior authorization policies for all or some impacted payers.
                    </P>
                    <P>Some commenters expressed support for CMS's exclusion of drugs from the proposed requirements and CMS's decision to defer Prior Authorization API requirements for drugs to future rulemaking. Multiple commenters recommended that CMS make clear the exclusion of drugs from all the requirements in a final rule.</P>
                    <P>
                        <E T="03">Response:</E>
                         We believe it is clear throughout this final rule that none of the prior authorization policies apply to any drugs covered by any impacted payer. However, based on the overwhelming number of comments in support of our reconsideration of the policy, and additional conversations with SDOs and stakeholders, we will consider options for future rulemaking to address improvements to the prior authorization processes for drugs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed disappointment that CMS excluded outpatient prescription drugs from the prior authorization process and Prior Authorization API policies in the proposed rule, explaining that drug prior authorizations constitute the majority of all prior authorizations. Multiple commenters recommended that CMS reconsider the exclusion of drugs from the proposed rule and suggested that CMS expand a final rule to include outpatient prescription drugs covered under a medical benefit.
                    </P>
                    <P>A few commenters specifically requested that CMS include drugs covered under a medical benefit in the prior authorization process and Prior Authorization API policies in the final rule and explained that the exclusion was troubling because health plans may cover physician-administered drugs and specialty drugs through a patient's medical benefits, including specialty drugs. A commenter urged CMS to include administered drugs, which are inextricably related to other provider services. Some commenters stated that by failing to include administered drugs throughout the proposed rule, CMS is failing to address the biggest culprit of delay to timely care and administrative burden for cancer patients. Commenters described barriers to access for prescriptions for specialty drugs, cancer drugs, and certain drugs for chronic conditions that require ongoing re-authorizations. The commenters believed that including prescription drugs in our prior authorization policies would improve the effectiveness of this final rule and would support CMS's goals of reducing barriers and burdens in health care.</P>
                    <P>
                        <E T="03">Response:</E>
                         While we acknowledge the request for reconsideration, when making the decision to exclude prescription drugs from the proposed rule, we believed there would be operational complexities in applying the requirements of this rule to prior authorization for prescription drugs under current conditions and did not anticipate the overwhelming response to that exclusion under current conditions. Based on the scope and breadth of the comments, it is essential for us to conduct a thorough evaluation of both existing policies and standards, and the impact any mandatory changes will have on impacted payers, providers, and patients, as well as on other policies before making a proposal for public consideration. We are committed to ensuring transparency of the process, and the development of the right policy to support all entities who might benefit. We anticipate engaging with the public on this topic in the near future and encourage the public to provide additional feedback.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters questioned whether impacted payers are permitted to include the functionality necessary to conduct prior authorization for drugs via the Prior Authorization 
                        <PRTPAGE P="8766"/>
                        API. A commenter also requested that CMS require all payers to include drug-related prior authorization requirements in the Prior Authorization API to ensure prescribers have ready access to uniform policies, and patients have timely access to their medications. Another commenter recommended that CMS explain that even if prescription drugs are excluded from the requirements, the rule does not prohibit the sharing of drug prior authorization data via the Patient Access, Provider Access, and Payer-to-Payer APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we did not propose a requirement for prior authorization policies for drugs to be included in the Prior Authorization API, payers may add such coverage rules and requirements to their APIs; nothing in this final rule prohibits broader use of the required Prior Authorization API by impacted payers and we encourage them to do so to the extent permitted by law. The scope of the IGs for the Prior Authorization API includes prior authorization for medications covered under a medical benefit. We describe the IGs and the Prior Authorization API in further detail in section II.D.2. of this final rule. However, we note that a FHIR API cannot be used with a National Council for Prescription Drug Programs (NCPDP) SCRIPT standard because the data elements have not yet been mapped. Also, the HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG states it “SHOULD NOT be used for any medication that is covered under a prescription drug program benefit where Prior Authorization is provided by another electronic exchange process (for example, NCPCP SCRIPT).” 
                        <SU>7</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             Health Level Seven International (n.d.) Use Cases and Overview. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/davinci-pas/usecases.html#scope-of-work-flow.</E>
                        </P>
                    </FTNT>
                    <P>We confirm that nothing would prohibit an impacted payer from sharing the same information about prior authorizations for drugs that they are required to share for items and services via the Patient Access, Provider Access, and Payer-to-Payer APIs, if they choose.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification on whether the prior authorization requirements would apply to supplies dispensed at a pharmacy, such as diabetic test strips. This commenter stated that an API would likely not provide any additional benefit or improve the timeliness of a decision and might increase handling timeframes while the API is in the early stages of use. This commenter recommended that pharmacy dispensable supplies maintain their current timeframes for coverage decisions. Another commenter recommended that CMS require impacted payers to include durable medical equipment (DME) administered under the DME benefit in the Prior Authorization API. Another commenter sought clarification on whether therapeutic devices are excluded from the Prior Authorization API requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Supplies, including those dispensed at a pharmacy and DME, that are considered medical benefits and are not prescription drugs, are subject to the prior authorization requirements of this final rule. Payers will be required to include these supplies in their APIs, to the extent they are covered as a medical benefit and require prior authorization. DME, for example, includes continuous glucose monitors, test strips, lancets, orthotics, wheelchairs, and other devices. All prior authorizations covered as a medical benefit, including those for DME, supplies dispensed at a pharmacy, or therapeutic devices, must still meet the timeframe requirements established in this final rule, regardless of whether the request is made through an API or other means, as described in section II.D.4. However, for MA-PDs, this final rule excludes the entire scope of “Part D drugs,” as defined at 42 CFR 423.100, from the scope of the prior authorization requirements; therefore, certain supplies that are included in the definition of Part D drugs at 42 CFR 423.100 are not subject to the prior authorization requirements adopted here.
                    </P>
                    <HD SOURCE="HD3">4. Impacted Payers</HD>
                    <P>As stated previously, certain portions of this final rule apply to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We received numerous comments regarding applicability to the payers impacted by the rule and summarize these comments and responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported CMS's proposed categories of impacted payers for this rule. Specifically, commenters supported the inclusion of Medicaid and CHIP FFS, which were excluded from the payer to payer data exchange requirements in the CMS Interoperability and Patient Access final rule, and MA plans, which were excluded in the December 2020 CMS Interoperability proposed rule. Commenters noted that the benefits of interoperable data exchange will only accrue if there is widespread adoption by payers across the health care system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for the proposed types of impacted payers and agree that the more payers that implement the requirements of this final rule, the greater the beneficial impact will be on patients.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested clarification as to whether dental plans that provide coverage to MA enrollees or Medicaid beneficiaries are impacted payers and encouraged CMS to exclude those plans, akin to the exclusion of QHP issuers on the FFEs offering only SADPs. Another commenter specifically encouraged CMS not to exclude SADPs and to include dental plans for MA and Medicaid or CHIP managed care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose new interoperability or prior authorization standards on SADPs on the FFEs because they have relatively lower enrollment and premium intake compared to individual market medical QHPs. Requiring those plans to comply with the requirements in this final rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. These plans are therefore outside the scope of this final rule. We appreciate input from commenters who view prior authorization and interoperability as important for SADP enrollees and will continue to monitor this issue and work with stakeholders to understand how to best meet patient needs while considering the potential burden on payers.
                    </P>
                    <P>For Medicare beneficiaries enrolled in MA plans, when dental coverage is a supplemental benefit covered by the MA plans, it is offered by the MA organization, directly or through contract arrangements the MA organization uses to provide the MA supplemental benefit. Regardless of the mechanism, the dental coverage is part of the MA plan itself and offered under the MA organization's contract and bid with CMS, not a separate plan. MA organizations can project expenditures to comply with the policies in this final rule to incorporate into their overall operational costs when setting premiums.</P>
                    <P>
                        An organization that has a risk-based contract directly with a state to provide dental benefits only to Medicaid and CHIP beneficiaries is usually a PAHP. We proposed, at 42 CFR 438.210 and 438.242 for Medicaid (applicable to separate CHIP through existing cross-references at 42 CFR 457.1230(d) and 457.1233(d)), that all PAHPs other than Non-Emergency Medical Transportation (NEMT) PAHPs, including those that cover dental benefits, would be subject to the requirements of this rule. Per 42 CFR 438.4, capitation rates, which are 
                        <PRTPAGE P="8767"/>
                        required for all risk-based MCOs, PIHPs, and PAHPs, must be projected to provide for all reasonable, appropriate, and attainable costs that are required under the terms of the contract and for the operation of the managed care plan for the time period, as well as the population covered under the terms of the contract, in addition to meeting specific additional requirements at 42 CFR 438.4 through 438.7. Similarly, for separate CHIP, per 42 CFR 457.1201(c) and 457.1203(a), capitation rates are based on public or private payment rates for comparable services for comparable populations and must represent a payment amount that is adequate to allow the MCO, PIHP, or PAHP to efficiently deliver covered services to beneficiaries in a manner compliant with contractual requirements. Therefore, the concerns of upward pressure on premiums that impact participation that are applicable to SADPs offered on the FFEs are not present for Medicaid and CHIP risk-based managed care plans.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS define the term “payer” to encompass health insurance issuers and group health plans subject to the Public Health Service Act. Multiple commenters expressed their concern that private payers, commercial plans, and employer-sponsored plans would not be subject to the rule requirements. A commenter expressed concern regarding the 150 million Americans who are in employer-sponsored coverage, who may not have access to the benefits of the proposed rule.
                    </P>
                    <P>Another commenter suggested that CMS could use its authority over the public sector Consolidated Omnibus Budget Reconciliation Act (COBRA) group health plans to extend interoperability requirements to those payers.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters supporting implementation of the policies by private payers, commercial plans, and employer-sponsored plans. However, we proposed to impose these requirements under our authority to regulate issuers in the Exchanges that CMS operates, which does not apply to health insurance issuers and group health plans outside the FFEs. There is nothing prohibiting those payers from implementing the provisions in this final rule voluntarily, as long as there are no conflicts with other Federal or state laws, and we do encourage those plans to voluntarily meet the requirements of this final rule to allow patients they cover to have the same interoperable access to their data as impacted payers are required to provide.
                    </P>
                    <P>Title XXII of the Public Health Service (PHS) Act applies COBRA requirements to group health plans that are sponsored by state or local government employers. They are sometimes referred to as “public sector” COBRA to distinguish them from the Employee Retirement Income Security Act of 1974 (ERISA) and Internal Revenue Code requirements that apply to private employers. We did not make any proposals regarding public sector COBRA plans, so they are not included as impacted payers in this final rule, but we will consider whether we can and should propose similar interoperability requirements on such plans in future rulemaking.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification regarding why CMS exempted SHOP issuers from the proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed in the proposed rule, we proposed to exclude QHP issuers offering only QHPs in the FF-SHOPs. We believe that the proposed standards would be overly burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and issuers offering only QHPs in the FF-SHOPs, which have relatively lower enrollment and premium intake compared to individual market medical QHPs, to comply with our proposals, could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS work with ONC and other Federal agencies, such as the Veterans Administration (VA), the U.S. Department of Defense (DoD), and other government payers, to bring additional data into the interoperability universe.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We continue to work with ONC and agencies across the Federal Government to move toward a fully interoperable health care system. We are committed to sharing any insights and best practices from our experience working with impacted payers with other agencies that provide health care coverage to inform their own interoperability goals. These are independent agencies over which HHS has no authority.
                    </P>
                    <HD SOURCE="HD3">5. Withdrawal of Proposed Rule</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we explained that we were withdrawing the December 2020 CMS Interoperability proposed rule (87 FR 76239). We received multiple comments in support of this decision.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters supported our withdrawal of the December 2020 CMS Interoperability proposed rule. Several commenters expressed that the burden of prior authorization has grown since that proposed rule was published and voiced their support for finalizing our proposals.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support and believe that the proposals that we are now finalizing reflect the feedback we received from the health care industry.
                    </P>
                    <HD SOURCE="HD3">6. National Directory of Healthcare</HD>
                    <P>On October 22, 2022, we released a Request for Information (RFI) (87 FR 61018) to solicit public comments on establishing an NDH that could serve as a “centralized data hub” for health care provider, facility, and entity directory information nationwide. We also received many comments to this proposed rule that discussed the possibility of an NDH, particularly to discover payers' digital endpoints (in this case, a FHIR server's URL or IP address) to facilitate our Payer-to-Payer API policy.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters stated that the lack of a national directory makes it difficult to identify digital endpoints to facilitate payer to payer data exchange. Multiple commenters also expressed how important an NDH would be to the success of a Provider Access API, because as information on provider digital endpoints remains limited, widespread access to such a directory could advance efforts to connect payers to providers. Commenters urged CMS to establish an NDH before the API compliance dates and explained that not doing so could result in an industry-wide scramble and search for verified plan endpoints necessary for implementation. A commenter recommended that CMS establish and maintain a national payer directory that includes verified information on payers, including their API endpoints, contact information for their API project managers, and their readiness for participation in payer to payer data exchange. Another commenter stated they are currently trying to set up their own Payer-to-Payer API and encountered problems without a centralized location of payer endpoints. This led to issues identifying a new member's previous payer and making secure connections to exchange information. A commenter cautioned that a draft version of the National Directory IG developed by the FHIR at Scale Taskforce (FAST) originally published in September 2022 
                        <SU>8</SU>
                        <FTREF/>
                         describes 
                        <PRTPAGE P="8768"/>
                        a payer to payer data exchange but is based on the projected existence of a national directory of payer endpoints and governance framework. A commenter noted scalability issues that could arise without a national directory of endpoints to connect in a unified and meaningful manner.
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             Health Level Seven International (n.d.). National Directory of Healthcare Providers &amp; Services (NDH) Implementation Guide. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/fhir-us-ndh/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response:</E>
                         We understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization API requirements. Without such a directory, payers would need to discover other payers' endpoints one by one, and each payer would have to maintain a list of payers that they have previously connected with for data exchange. The Trusted Exchange Framework and Common Agreement (TEFCA) provides a directory of digital endpoints that can be used by TEFCA Participants.
                        <SU>9</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             Office of the National Coordinator for Health Information Technology (n.d.). Trusted Exchange Framework and Common Agreement (TEFCA). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.</E>
                        </P>
                    </FTNT>
                    <P>Additionally, CMS is committed to exploring an NDH that contains payers' and providers' digital endpoints to facilitate more interoperable data exchange in healthcare for a variety of use cases, including support for the Payer-to-Payer, Provider Access, and Prior Authorization APIs.</P>
                    <HD SOURCE="HD1">II. Provisions of the Proposed Rule and the Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Patient Access API</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25558), in order to give patients access to their own health information in a way most meaningful and useful to them, we required impacted payers to share, via FHIR APIs, certain information including patient claims, encounter data, and a set of clinical data that patients can access via health apps. Claims and encounter data, used in conjunction with clinical data, can offer a broad picture of an individual's health care experience. Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual's record are locked in disparate, siloed data systems. With patient data scattered across these disconnected systems, it can be challenging for providers to get a clear picture of the patient's care history, and patients may forget or be unable to provide critical information to their provider. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care.</P>
                    <HD SOURCE="HD3">2. Enhancing the Patient Access API</HD>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25558-25559), we adopted regulations that require certain payers, specifically MA organizations (at 42 CFR 422.119), state Medicaid and CHIP FFS programs (at 42 CFR 431.60 and 457.730), Medicaid managed care plans (at 42 CFR 438.242(b)(5)), CHIP managed care entities (at 42 CFR 457.1233(d)), and QHP issuers on the FFEs (at 45 CFR 156.221), to implement and maintain APIs that permit patients to use health apps to access specified data. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and patient cost-sharing); encounters with capitated providers; and clinical data, including laboratory results, with a date of service on or after January 1, 2016, as maintained by the payer. Payers must make those data available via the Patient Access API no later than 1 business day after a claim is adjudicated or encounter or clinical data are received. In the CMS Interoperability and Prior Authorization proposed rule, we proposed various changes to enhance the Patient Access API that are discussed further elsewhere. We also received comments about the Patient Access API more generally, which we summarize and respond to in this section.</P>
                    <P>
                        To support the ongoing maintenance of the Patient Access API, we are requiring certain specifications and recommending certain IGs, as further discussed in this section and in section II.G. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Patient Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1) and OpenID Connect Core 1.0 at 45 CFR 170.215(e)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Patient Access API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.
                        <SU>10</SU>
                        <FTREF/>
                         We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) STU 2.0.0, HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and HL7® FHIR® Da Vinci PDex US Drug Formulary IG STU 2.0.1. We also direct readers to section II.G. of this final rule for a discussion of the standards for the Patient Access API, and Table H3 for a full list of the required standards and recommended IGs to support API implementation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). 
                            <E T="03">Standards Version Advancement Process (SVAP).</E>
                             Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed general support for the Patient Access API, as it would promote transparency and improve patient access to health data. Many commenters agreed that the proposed modifications to the Patient Access API would improve patient engagement, shared decision making, and be an opportunity for patients to improve health literacy. Commenters stated that it is critical to ensure that data are shared interoperability to prevent unnecessarily restrictive or expensive proprietary systems from inhibiting patient and provider access. A commenter noted that the API places the patient at the center of care, which could lead to improvements in quality care and a seamless patient experience. Other commenters noted that it will help improve predictability for patients and help them identify potential violations in mental health parity law and facilitate better communication between patients and providers. Another commenter noted that the most convenient way for patients to access their health information is via apps.
                    </P>
                    <P>Multiple commenters expressed support for the standardization of the Patient Access API across different payer types and coverage programs. A commenter stated that establishing standardized processes for the Patient Access API would benefit patients and enable them to have efficient and secure access to their records while maintaining their privacy.</P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback and will continue to 
                        <PRTPAGE P="8769"/>
                        look for ways to drive adoption and use of the Patient Access API to benefit patients. We agree that requiring a standard API will unlock potential for developers to create patient-friendly apps.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Other commenters stated that they do not believe the Patient Access API will be a dominant means for accessing health care data because patients may get similar or better information elsewhere. Commenters stated that they have not seen significant uptake of health apps since the implementation of the Patient Access API. Commenters relayed that while they believe in the potential for the Patient Access API to improve the utility and portability of patient medical information, they have not seen robust utilization of these tools, possibly because many payers have their own portals. Some commenters believe that their members prefer to speak with a customer service representative, for instance, to discuss the status of their claims. Some payers noted that although they currently have a low rate of members using apps, they anticipated higher utilization as younger cohorts, who are more familiar with how smartphone apps can benefit their care, reach the age of Medicare eligibility.
                    </P>
                    <P>A commenter flagged that the Patient Access API could result in administrative costs being spread over a smaller than expected user base due to its low utilization. They recommended that CMS continue to monitor the utilization of the proposed APIs as it considers new functionalities and requirements.</P>
                    <P>Multiple commenters expressed concerns that certain patients may not be able to access the Patient Access API due to a variety of factors (for example, limited access to technology/internet, software, or apps or low digital literacy), and they encouraged CMS to consider how it can help patients with limited digital or broadband access to have equitable access to necessary coverage information. Stating that some patients may not have access to the appropriate software or app, multiple commenters recommended that CMS require states and other entities to continue to provide written notices instead of relying on electronic communication via the Patient Access API. Commenters also recommended that CMS continue to monitor the Patient Access API usage and closely track any potential disparities in access due to social determinants of health (SDOH) or differences in digital literacy.</P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that some patients cannot or may not want to access their health information electronically or through a health app. Nothing in this rule will require patients to use the Patient Access API to access their health information. Nor will the rule change any applicable obligation for payers to make information available in non-electronic formats, should such a requirement exist. For example, 42 CFR 435.918(a) requires Medicaid agencies to give individuals the choice whether to receive notices electronically or by mail. Similar requirements for MA organizations can be found at 42 CFR 422.2267(d)(2). Furthermore, under the HIPAA Privacy Rule, covered entities generally must provide individuals access to their PHI in the form and format requested by the individual, if it is readily producible in such form and format; or, if not, in a readable hard copy form or such other form and format as agreed to by the covered entity and the individual.
                        <SU>11</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.524(c)(2)(i).
                        </P>
                    </FTNT>
                    <P>However, making available digital tools, such as standardized APIs and health apps that can access them, aligns with how many people interact with other industries today, such as banking and e-commerce. Making health information similarly available and interoperable broadens patients' options for accessing their records. While many patients may be satisfied using their payer's portal, and we do not wish to take that option away from them, using proprietary systems and data formats has led to a health care system where patient data are fragmented and often difficult to exchange between parties. Entities such as HIEs, health apps, and TEFCA Participants and Subparticipants may be able to gather data from payers, providers, and other sources to create a more comprehensive patient record than could be maintained by the payer alone. Advances in nationwide data sharing, such as payers' Patient Access APIs, connections across HIEs, and exchange enabled by TEFCA, can facilitate secure and reliable access to these data sources. That is the reason that CMS and HHS are invested in establishing open standards and requirements for payers and providers to use standardized technology. While many patients are most familiar with their payer's portal, until the Patient Access API provisions went into effect on January 1, 2021, their options may have been limited. We also anticipate that adoption will take time as patients learn about their options and choose methods for accessing their health information that work best for them.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS ensure that the Patient Access API allow caregivers and dependents to have access where patients have provided consent. A commenter urged CMS to explain how an individual can ensure caregivers have access to their health information via the Patient Access API. Another commenter recommended that CMS explain that representatives should be included in all relevant communication and considered as payers develop the API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Per the HIPAA Privacy Rule at 45 CFR 164.502(g), a personal representative is a person authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney). With limited exceptions, a personal representative is treated as the individual for purposes of the HIPAA Privacy Rule. Similarly, our existing Patient Access API policies (at 42 CFR 422.119(a) and (b)(1), 431.60(a) and (b), and 457.730(a) and (b) and 45 CFR 156.221(a) and (b)) explicitly apply to patients' personal representatives.
                    </P>
                    <P>Payers likely have different processes and policies for designating someone as a personal representative under the HIPAA Privacy Rule and also may be subject to similar state laws. Nothing in this rule will require a change to those processes. Therefore, patients and personal representatives should contact their payer for the steps to ensure appropriate access to information via the Patient Access API. We do not explicitly require impacted payers to send to their patients' personal representatives the required educational resources. However, payers are required to post those resources on their public websites and to convey them via other appropriate mechanisms through which they ordinarily communicate with current patients. If payers send other resources to personal representatives on a patient's behalf, then educational resources should be sent to them as well. In addition, there may be program- or state-specific requirements to transmit such resources to a patient's personal representative.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that CMS require payers to update patient information that they are told is incorrect by a patient or provider.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. The Patient Access API does not require the impacted payer to 
                        <PRTPAGE P="8770"/>
                        include the capability to send information from a patient to a payer. Therefore, while patients have the right under the HIPAA Privacy Rule to request that a HIPAA-covered entity (such as a provider or payer) amend their record, that functionality is out of scope for the Patient Access API.
                    </P>
                    <HD SOURCE="HD3">a. Prior Authorization Information</HD>
                    <P>To enhance our policy finalized in the CMS Interoperability and Patient Access final rule, we proposed in the CMS Interoperability and Prior Authorization proposed rule to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. We stated that this proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which a payer has data in the patient's record, as discussed further in this section. We also proposed that the Patient Access API must include certain information about prior authorizations within 1 business day of receipt of, or change of status to, the prior authorization. The primary goal of the Patient Access API is to give patients access to their health information, and by expanding patient access to prior authorization information, we aim to help patients be more informed decision makers and true partners in their health care.</P>
                    <P>As discussed in section I.D. of this final rule, our prior authorization proposals did not apply to drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, drugs that may be dispensed or administered in a pharmacy or hospital, or over-the-counter (OTC) drugs.</P>
                    <P>In section II.D. of this final rule, we finalize several proposals focused on making the prior authorization process less burdensome for providers and payers, which we anticipate will reduce delays in medically necessary access to covered items and services and improve patient outcomes. Giving patients access to information about prior authorization requests and decisions will enable them to take a more active role in their own health care.</P>
                    <P>We are finalizing our proposal to require impacted payers to provide patients, through the Patient Access API, with access to information about prior authorization requests and decisions made for their care and coverage. However, we are finalizing a modification to our proposal and not requiring payers to share the quantity of items or services used under a prior authorization or unstructured documentation related to a prior authorization, as discussed elsewhere in this final rule. We are finalizing these changes with compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year after the proposed 2026 compliance dates.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A significant majority of commenters expressed support for CMS's proposal to include prior authorization information in the Patient Access API. Commenters listed multiple benefits to making prior authorization information available via the Patient Access API, including empowering patients in their care, reducing the burden of repeated inquiries to payers, and facilitating faster decisions by allowing patients to help providers submit the necessary documentation. Multiple commenters highlighted current challenges for patients to access their prior authorization information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' feedback confirming the significant burden that prior authorizations processes place on patients. We received comments from across the industry that indicated that those processes could be improved by interoperable data exchange. Those comments have informed the policies we are finalizing to require impacted payers to make available via the Patient Access API certain information about prior authorizations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concerns that because many patients do not have an overall understanding of the prior authorization process, giving patients access to prior authorization information would add to existing confusion, and that this information may be overwhelming. Some commenters stated that they do not believe that additional requirements and burden on impacted payers around the Patient Access API are warranted based on current app adoption by patients. The commenters stated that there should be greater Patient Access API use before adding more requirements to the Patient Access API.
                    </P>
                    <P>Commenters cautioned against creating any expectations for patient involvement in a prior authorization process that they may not understand and over which they may have little control. Other commenters recommended that CMS explore strategies to promote access to timely prior authorization-related information for patients who cannot or do not want to use health apps.</P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that not all patients will want to access their prior authorization data, and some may not be able to fully understand the information that is presented to them. However, we do not believe that this is a sufficient justification for not making those data available to patients who want that access and insight into their care. We strongly encourage payers to make data transparent and explain the processes involved in a patient's coverage in an easily understandable manner.
                    </P>
                    <P>We do not intend to create expectations for patient involvement in the prior authorization process but want to make that opportunity available where it can be beneficial to expedite prior authorization decisions. To the extent that program-specific requirements do not already require such disclosures to enrolled patients, we urge payers to make prior authorization information available to patients regardless of what method they use to inquire about their coverage or care—whether that is an online patient portal, a phone call to customer service agents, or an email inquiry. However, our proposals in this section only addressed information available to patients via the Patient Access API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters stated that, because prior authorization requests today are commonly submitted via multiple modalities, CMS should modify its proposal to require prior authorization information be included in the Patient Access API only if it came from requests submitted via a Prior Authorization API. Commenters flagged that prior authorization data received in non-standard formats, such as fax, would require significant resources for many payers to translate into a standard format to be shared via the Patient Access API. Commenters stated that adoption of electronic prior authorization by providers would be gradual, and it would be administratively complex and burdensome to require payers to convert prior authorizations submitted via phone or fax to electronic format. The commenters recommended that CMS make sharing prior authorizations received via phone or fax optional for payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that data submitted for prior authorization requests via non-electronic or non-standardized modalities could require an additional step to make available through the Patient Access API. However, we also note that the burden of ingesting data from non-standard and 
                        <PRTPAGE P="8771"/>
                        non-electronic requests into a payer's prior authorization systems exists regardless of the requirement to share data with the patient. While sharing requests submitted via a Prior Authorization API might be simpler, as they are already in a FHIR format, we do not believe that the burden of converting data from the format payers currently use in their prior authorization systems outweighs the benefit of making prior authorization information available to patients. We also note that the same prior authorization data are largely required to be shared via the Provider Access and Payer-to-Payer APIs, thus creating an economy of scale by spreading the benefit to all parties while the burden of data translation would only have to happen once. We believe that all patients should have access to their prior authorization information, regardless of the process between their provider and payer.
                    </P>
                    <P>In section II.D. of this rule, we are finalizing a requirement for impacted payers to implement and maintain a Prior Authorization API and in section II.F. of this rule, we are finalizing a measure within MIPS to incentivize providers to use that Prior Authorization API. We are finalizing those policies to promote the adoption of electronic prior authorization and, therefore, expect that as electronic prior authorization increases over time, the overall burden of making available prior authorization information submitted and received through other modalities will decrease. We believe that payers will also encourage their providers to use electronic prior authorization to decrease that burden, which will lead to greater interoperability and data availability for patients.</P>
                    <P>Also, if we required only prior authorization data submitted via a Prior Authorization API to be available via the Patient Access API, we would be excluding patients whose providers may not be able to implement electronic prior authorization for technological or other reasons. Therefore, we are finalizing a Patient Access API policy that covers data from all prior authorizations, regardless of the medium through which the payer receives the request.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted challenges that state Medicaid agencies would face to include prior authorization data in the Patient Access API. The commenter stated that there are differences between how states process prior authorizations today, with some state Medicaid agencies relying on manual processes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         State expenditures on designing, developing, installing, enhancing, or operating state Medicaid systems that can conduct electronic prior authorization may be eligible for enhanced Federal financial participation. Implementation of the Prior Authorization API should facilitate a faster and more automated workflow to make prior authorization data available. We encourage states to take this opportunity to determine whether modernizing prior authorization systems beyond the implementation of a Prior Authorization API can improve their prior authorization processes. We describe the enhanced Medicaid Federal matching percentages in fuller detail in section II.E. of this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS explain that the information it is requiring to be available does not need to be “pushed” to a patient app, but should be available for query, if a patient chooses to use their app to retrieve their information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that the Patient Access API works on a query mechanism and not a “push.” Our final policy requires that the data be available for a patient's app to query and receive from an impacted payer.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters suggested that patients should be able to provide supporting documentation directly to their payer via the Patient Access API. The commenters stated that patients should have the choice to submit prior authorization requests themselves, or to have a provider or third party do it, and should also have the option to initiate, monitor, and appeal prior authorization decisions. Another commenter believed that patients should be able to challenge decisions and report delays.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose to require impacted payers to accept a prior authorization request or supporting documentation directly from patients. We fear that this would create confusion about the prior authorization process and whether the provider or patient is ultimately responsible for the submission of prior authorization requests and documentation. Providers are in the best position to understand the clinical requirements to obtain prior authorization and are responsible for using their clinical judgment to decide on the best course of treatment. As discussed, it is valuable for patients to have transparency into that process and be able to assist providers to submit necessary information. However, without a clinical understanding, patients may submit extraneous or irrelevant information. Furthermore, patients likely do not have systems that would be able to communicate and submit information via the Prior Authorization API. That would require the availability of an alternative system and negate some of the efficiencies the Prior Authorization API will bring to the prior authorization process. Taken together, such a requirement would add burden to payers and may end up delaying the prior authorization decision process. Nothing in this rule will prohibit a payer from accepting information directly from patients if that would benefit the payer's processes or patient care. Furthermore, payers are already required to have a process in place for patients or providers to appeal prior authorization decisions and to file a complaint with the appropriate Federal or state oversight agency.
                    </P>
                    <HD SOURCE="HD3">i. Compliance Dates</HD>
                    <P>For the requirement to include prior authorization information in the data available via the Patient Access API, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters supported the proposed compliance dates. However, several commenters recommended that the compliance dates for adding prior authorization information to the Patient Access API be accelerated—with recommendations for July 1, 2024, January 1, 2025, or 12 months after the finalization of this rule. Multiple commenters recommended earlier compliance dates due to the significant impact that this information could have on patient empowerment and information transparency.
                    </P>
                    <P>
                        Conversely, multiple commenters recommended that CMS delay the proposed compliance date until the Prior Authorization API, discussed in section II.D. of this final rule, is widely adopted. Commenters stated that while the technical data standards may be mature, CMS should also consider the status of payers' data infrastructure, which may not have prior authorization information in a structured format to be shared via the Patient Access API. As discussed previously, some commenters recommended limiting the requirement to make prior authorization data available through the Patient Access API only to data contained in standardized HIPAA-compliant electronic prior authorization transactions, such as those facilitated by the Prior Authorization 
                        <PRTPAGE P="8772"/>
                        API. These commenters recommended that CMS work with payers, providers, health IT developers, and consumer advocacy groups to first advance electronic prior authorization uptake before determining appropriate compliance dates. A commenter suggested CMS consider additional flexibilities and exceptions for impacted entities unable to comply with the proposed 2026 compliance dates.
                    </P>
                    <P>Another commenter recommended delaying the compliance dates by another 2-3 years to allow for simultaneous implementation with the “Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard” proposed rule (hereinafter referred to as the HIPAA Standards for Health Care Attachments proposed rule) (87 FR 78438).</P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing public comments, we have elected to finalize the provision with a 1 year delay to the compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). While making data related to prior authorization available to patients is necessary and urgent, we also understand that it will take time for payers to implement the policies we are finalizing. We believe that the additional year will allow payers to ensure a smooth rollout of this additional functionality. However, we encourage payers to meet the requirements of this rule as soon as possible to benefit their patients.
                    </P>
                    <P>We decline to delay the compliance date for including prior authorization information in the Patient Access API until after the Prior Authorization API compliance dates and are finalizing the same compliance dates for both this policy and the Prior Authorization API. The purpose of the Prior Authorization API is to facilitate the exchange of structured prior authorization data, and we agree that receiving requests electronically may expedite payers' ability to make that information available to patients. However, even after the Prior Authorization API compliance dates, we expect that a number of prior authorizations are going to be submitted through other channels (hopefully in declining number). As discussed previously, payers will need to have the ability to share prior authorization information that is submitted via channels other than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027 compliance dates, we are providing payers with an additional year beyond what we proposed to implement the needed functionality within their internal systems.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that prior authorization decisions issued before the compliance dates should not be required to be available via the Patient Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We proposed, and are finalizing, that impacted payers must give patients access to existing prior authorization information maintained by the payer beginning on the compliance dates. In the CMS Interoperability and Patient Access final rule, we required payers to make available the specified data they maintained with a date of service on or after January 1, 2016, which meant that patients had access to their historical data beginning on the January 1, 2021, compliance date. That date range also applies to the prior authorization data that must be included. However, unlike the other categories of data, there is a period of time after which prior authorization data no longer needs to be available. As discussed elsewhere in this final rule, prior authorization information must be shared while the prior authorization is active and for 1 year after the last status change. As of the compliance dates, payers must make all required data available via the Patient Access API. However, it is unlikely that a significant number of patients will have data from many years before the compliance dates. On January 1, 2027 (or the actual compliance date), payers will be required to make available data about all active prior authorizations, regardless of how long they have been active, and any requests that have had a status update within the previous 1 year period (that is, since January 1, 2026, if a payer implements on these changes on that day).
                    </P>
                    <HD SOURCE="HD3">ii. Data Content</HD>
                    <P>We proposed that the information required to be available through the API would include the prior authorization request and related administrative and clinical documentation, including all of the following:</P>
                    <EXTRACT>
                        <P>(1) The prior authorization status.</P>
                        <P>(2) The date the prior authorization was approved or denied.</P>
                        <P>(3) The date or circumstance under which the authorization ends.</P>
                        <P>(4) The items and services approved.</P>
                        <P>(5) The quantity used to date under the authorization.</P>
                        <P>(6) If denied, the specific reason why the request was denied.</P>
                    </EXTRACT>
                    <P>In section II.D.3. of this final rule, we are finalizing that in the case of a prior authorization denial, the payer must give the provider a specific reason for the denial that is separate from the content requirements for the APIs finalized in this rulemaking. Including the reason in the Patient Access API can help patients understand why a payer denied a prior authorization request. The administrative and clinical documentation related to a prior authorization request that we proposed must be shared through the Patient Access API would include any materials that the provider sends to the payer to support a decision, for example, structured or unstructured clinical data including laboratory results, scores or assessments, past medications or procedures, progress notes, or diagnostic reports. For the reasons discussed, we are finalizing modifications to our proposals to not require impacted payers to include “the quantity used to date” or unstructured documentation in the data available via the Patient Access API.</P>
                    <P>As further discussed in sections II.B. and II.C. of this final rule, we are requiring impacted payers to make available generally the same information about prior authorization requests and decisions via the Provider Access and Payer-to-Payer APIs. In this way, these prior authorization data can be available to all relevant parties. We note that the requirement to share information about prior authorizations via the Patient Access and Provider Access APIs is in addition to any notice requirements that apply to prior authorization requests and decisions, such as the requirement to notify providers of a decision within certain timeframes discussed in section II.D.5.b. of this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that CMS require payers to make data more actionable and descriptive by including detailed reasons why a prior authorization request is pending. Many commenters recommended a status for when certain services do not require prior authorization. Conversely, to make status updates simpler via the Patient Access API, multiple commenters suggested only having a pending, active, denied, or expired status update. A commenter requested clarification on whether, in our proposal, the listed “another status” was a status unto itself or used as a catch-all description of any statuses other than those listed.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we consider five basic statuses (pending, active, denied, 
                        <PRTPAGE P="8773"/>
                        expired, authorization not required) to cover the general scope of a prior authorization request and decision, we are neither defining the term “status” as used in this rule, nor these five basic statuses or the conditions under which they must be used by impacted payers. We understand that payers use a variety of processes and do not intend to prescribe exactly when a particular status must be used. Rather, we are indicating that impacted payers must make clear to patients (via the Patient Access API) and providers (via the Provider Access API discussed in section II.B. of this final rule), the status of a prior authorization decision, such as when it is pending, approved, denied, or expired or a request has been submitted for an item or service that does not require prior authorization. We expect payers will generally use those statuses, but they are also welcome to use other statuses that provide additional information or are more specific to the particular payer's process. Such statuses should be clear and understandable to patients and providers. For example, a payer could use statuses such as “under appeal” or “expired—approved quantity used.” However, in some cases, the status information available beyond “pending” could be meaningless to patients if it refers only to the payer's internal processes.
                    </P>
                    <P>We also agree that patients could benefit from payers making it clear through the Patient Access API when an item or service submitted for prior authorization does not require prior authorization for coverage. However, we emphasize that a mere query as to whether prior authorization is required would not create a record that needs to be shared via the Patient Access API (or the Provider Access API). For instance, a provider may use the HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) IG, which is the part of the Prior Authorization API that allows a provider to query whether a payer requires prior authorization before they will cover a specific item or service for a specific patient. Similar queries made through other channels, or submissions that are rejected for being unnecessary, need not be made available through the Patient Access API unless the request creates a record in the patient's data maintained by the payer. Though not required, impacted payers would be welcome to make that information available.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported our proposal that the Patient Access API enhance transparency by including a specific reason for denial. Commenters stated that including a reason for denial would help beneficiaries dispute decisions in a more effective manner. A few commenters urged CMS to require impacted payers to disclose via the Patient Access API the specific coverage or clinical criteria upon which the impacted payer relied to issue a denial.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we encourage payers to provide coverage or clinical criteria that they used to make a prior authorization decision if that information would help the patient or provider understand the prior authorization decision, many payers consider that specific information to be proprietary. In addition to potentially being proprietary, those clinical criteria may be significantly more complicated than the information we are requiring, and not easily understood by patients. Therefore, we did not propose to require that detailed clinical criteria for a prior authorization decision be shared with patients through the Patient Access API. Instead, we proposed and are finalizing that when a payer denies a prior authorization request, they must provide a specific reason for that denial through the Patient Access API. That reason may indicate which clinical criteria the patient did not meet to be approved for the items or services. We reiterate that the requirement that the specific reason for a denial be included in the Patient Access API is in addition to any other applicable requirements regarding notice of decisions, such as the requirement at 42 CFR 422.568(e) that MA organizations issue a notice containing specific content when denying a prior authorization request and similar requirements for Medicaid managed care plans at 42 CFR 438.210(c) and for health insurance issuers offering individual health insurance coverage (which includes QHP issuers on the FFEs) at 45 CFR 147.136(b)(3)(ii)(E).
                        <SU>12</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             For example, 45 CFR 147.136(b)(3)(ii)(E)(
                            <E T="03">3</E>
                            ) provides that individual health insurance issuers' notifications of any adverse benefit determination must include the reason or reasons for the determination along with the denial code and its corresponding meaning, and a description of the issuer's standard, if any, that was used in denying the claim. In the case of a notice of a final internal adverse benefit determination, this description must include a discussion of the decision.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters questioned whether CMS would provide standardized denial codes and how much flexibility payers will have to define denial reasons.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In this final rule, we are requiring impacted payers to provide a specific reason for a denial. We did not propose standardized denial codes or a specific set of denial reasons for payers to use. However, there is a list of standardized codes that must be used when a prior authorization decision is sent to a provider via the adopted HIPAA standard, which is maintained by the SDO X12.
                        <SU>13</SU>
                        <FTREF/>
                         While using those codes is not required for the Patient Access API, we strongly encourage payers and providers to evaluate the code set and make recommendations to X12 for updated or new denial codes, as appropriate. If those X12 denial codes meet the requirement for specificity, they could be used in both the HIPAA transaction and the Patient Access API.
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             X12 Standards (2022, August). Service Review Decision Reason Codes. Retrieved from 
                            <E T="03">https://x12.org/codes/service-review-decision-reason-codes.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters urged CMS to require payers to include plain language information about appealing a prior authorization decision, including processes to request internal review and external appeal of a decision and information about consumer programs to assist with appeals.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose to make that information available via the Patient Access API. Our educational requirements, discussed in the CMS Interoperability and Patient Access final rule (85 FR 25550-52), only cover using the Patient Access API and not the prior authorization process writ large. However, impacted payers are already required to include that information with a notice of denial.
                        <SU>14</SU>
                        <FTREF/>
                         For requirements to make information about the appeals process available to patients via other modalities, see further discussion in section II.D. of this final rule. Depending on the specific requirements of their program, impacted payers may be able to meet that requirement by providing notice about the appeals process via the Patient Access API.
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(e)(3) (for MA), 431.210(d) (for Medicaid), and 457.1180 (for CHIP) and 45 CFR 147.136(b)(2)(ii)(E)(
                            <E T="03">4</E>
                            ) (for QHP issuers on the FFEs).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS not require the prior authorization information included in the Patient Access API to include the “quantity used to date” requirement, because that information would come from payer claims data. Commenters explained that those data are not a reliable source for patients and providers to track the number of authorized services used to date because of the lag time for processing claims. As such, payers would not be able to update that information until claims have been submitted and processed for the items or services covered by the prior authorization, which could result in inaccurate information being given to 
                        <PRTPAGE P="8774"/>
                        a patient for weeks or months until claims are processed.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that payers may not always have accurate or current information about the quantity of approved items or services that a patient has used as of a specific date under a prior authorization. Payers must rely on claims data for that information, which are often not current because there is typically a time lag between when an item or service is rendered and when the claim is submitted and/or processed. If a patient knows that they have used some quantity of the approved items and services, but is not sure of the specific quantity, receiving inaccurate information from their payer about the quantity used to date would lead to confusion and possibly unnecessary inquiries that take patients, providers, and payers time to resolve. Therefore, we are not finalizing our proposal to include “quantity of approved items or services used to date” in the prior authorization information available via the Patient Access API. However, we are finalizing our proposal to require a total number of items or services approved under the prior authorization decision.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that administrative and clinical documentation sent by the provider for prior authorization requests be included in the Patient Access API. However, multiple other commenters recommended that CMS not finalize its proposal to include supporting documentation for prior authorization requests. Some commenters specifically recommended that CMS not require payers to include data or forms that were not sent in a standardized electronic manner, such as via the Prior Authorization API. The commenters expressed concern about the feasibility for impacted payers to provide information that they received in a non-electronic or unstructured format (such as scanned documents or PDFs) and whether third-party patient apps can access or display such documentation. Instead, commenters recommended that CMS focus on requiring that discrete data elements and structured data related to prior authorizations be available to patients. While some commenters expressed that structured data may be duplicative or unnecessary, a majority of commenters indicated that including such data would not be overly burdensome for payers.
                    </P>
                    <P>Other commenters requested clarification regarding what types of provider-generated documentation would be required and some recommended that CMS assess the prior authorization information requirements against information already available in the APIs to mitigate redundant or duplicative information.</P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing the comments, we agree that the burden of requiring impacted payers to make unstructured documentation available via the Patient Access API outweighs the benefits such documentation would provide, so we are finalizing a requirement that the Patient Access API must include structured administrative and clinical documentation submitted by a provider related to the prior authorization request.
                    </P>
                    <P>Structured documentation includes any data received from a provider and stored in the payer's system in a standardized format with defined data attributes, such as USCDI or FHIR. Examples of structured documentation include data sent by the provider via a transaction standard for prior authorization(s), which utilizes standard code sets, data sent via a Prior Authorization API in a format other than as an attachment, or structured questionnaires that a payer requires providers to fill out when making the prior authorization request. Unstructured data include any attachments submitted by providers, such as radiological scans, large PDFs of clinical data, or, generally, another file that a provider sends to the payer as an attachment to the prior authorization request.</P>
                    <P>We note that documentation received in an unstructured format does not need to be parsed and converted to structured data to be included in the Patient Access API. However, if a payer does parse the unstructured documentation to store the contained data in a structured format, those structured data would then be “maintained” by the payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538), and the payer would be required to make it available via the Patient Access API.</P>
                    <P>
                        At this time, the standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. The developing standard for exchanging attachments via FHIR APIs is the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG.
                        <SU>15</SU>
                        <FTREF/>
                         Version 2 of the IG completed the HL7 consensus-based process in 2023 and was published as an STU, indicating that it is being prepared for additional testing by implementers before being proposed for adoption. Without the FHIR standard, payers might implement unstructured documentation attachments within the Patient Access API in a variety of ways, which would lead to confusion and lack of interoperability. At this time, attachments exchanged via CDex are considered unstructured documentation and would not need to be made available via the Patient Access API as part of the prior authorization information. If the CDex becomes a mature standard, we may reconsider in future rulemaking whether it would be beneficial to share unstructured documentation as attachments via the Patient Access API.
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             Health Level Seven International (2023). Da Vinci Clinical Data Exchange. Retrieved from 
                            <E T="03">https://hl7.org/fhir/us/davinci-cdex/.</E>
                        </P>
                    </FTNT>
                    <P>We recognize that unstructured administrative and clinical documentation from a provider could be important to help patients understand the prior authorization process, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing will require impacted payers to make available any documentation that a provider sends to the payer to support a prior authorization request that is received in a structured format. Since we are finalizing that only structured data be made available, and structured data are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving patients access to information about their prior authorization processes.</P>
                    <P>We note that some of that information may already be available via the Patient Access API as clinical data. However, we believe that there is value to patients being able to ensure that the clinical information reviewed by the payer is accurate and up to date. Therefore, it is important for payers to make available the specific clinical data that they are looking at to decide on the prior authorization request, even if that information may be elsewhere in the patient's record.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that the Patient Access API should include information regarding whether the requesting provider is in-network or out-of-network, by requiring payers to fully implement the X12 270/271 transaction standards for health plan eligibility benefit inquiry and responses. Another commenter recommended that CMS require payers to make available via the Patient Access API the names and contact information for the in-network provider who can furnish the appropriate service within the time and distance standards required by law. Multiple commenters 
                        <PRTPAGE P="8775"/>
                        believed that patients should be able to access prior authorization information via the Patient Access API regardless of their provider. A commenter noted consideration for varying network adequacy standards and that a patient may need to seek care from an out-of-network provider. A commenter noted that Medicaid managed care plans have wide discretion for measuring provider network adequacy and that a patient's provider should be able to offer the same services for prior authorization despite their network status with the patient.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         This rule makes no distinction between in-network and out-of-network providers with regard to making prior authorization information available through the Patient Access API. Regardless of the requesting provider's network status, the required information must be shared with patients. We understand that it is important for patients to know whether the provider they are seeing is in their payer's network, but we do not believe that the appropriate place for that information is with prior authorization information. Furthermore, the FHIR API technical specifications and IGs for the Patient Access API are not built to include information on a provider's network participation. We note that in the CMS Interoperability and Patient Access final rule (85 FR 25563), we required MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to build and maintain a Provider Directory API. We encourage developers to integrate within their apps network information from payers' Provider Directory APIs for easy patient access.
                    </P>
                    <P>To the extent that a provider's network status may increase a patient's out of pocket costs, we encourage payers to inform patients before they receive items or services from an out-of-network provider to the extent that applicable programmatic requirements do not already require the payer to do so.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that a log of all instances that a patient's data was transferred via the Provider Access and Payer-to-Payer APIs should also be documented and accessible under the Patient Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose that payers must make that information available via the Patient Access API but encourage payers to do so for transparency with respect to when and with whom a patient's data are being shared. We will consider proposing to require this in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">iii. Timeline for Data Sharing</HD>
                    <P>We proposed to require impacted payers to make available, via the Patient Access API, information about prior authorization requests and decisions for items and services (excluding drugs) to patients no later than 1 business day after the payer receives the prior authorization request or there is another status change for the prior authorization. Examples of status changes include: a payer receives a request, a payer approves or denies a pending prior authorization request, or a provider updates a denied prior authorization request with additional information for reconsideration. We expect that impacted payers use a variety of terminology, but, generally, any meaningful change to the payer's record of the prior authorization request or decision will require an update to the information available to the patient.</P>
                    <P>We proposed 1 business day as the appropriate timeframe because patients need timely access to the information to understand prior authorization processes and their available care options. As discussed further in section II.D. of this final rule, we proposed to require payers to make much of the same information about prior authorization requests and decisions available via the Prior Authorization API during the decision-making process. In addition, we stated that because impacted payers would be required to have the ability to exchange prior authorization information electronically, it would be reasonable for them to share prior authorization information with patients within 1 business day of any update to the prior authorization request or decision.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed that the prior authorization process is opaque and burdensome to patients. Commenters stated that patients often wait for approval for critical items and services without status updates from their payer. Those commenters voiced support for the proposed requirement that payers make prior authorization information, including decision status and documentation information, available through the Patient Access API within 1 business day after the payer receives the request. Multiple commenters noted that this will provide greater transparency with respect to the prior authorization process.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters confirming that our proposed policies would ease the burden of prior authorization processes and benefit patients and providers. We agree that timely access to information about their prior authorizations is important to increase transparency and ensure that patients understand their care and coverage.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters, specifically payers, noted that the proposed 1 business day window may not be operationally feasible for payers. A commenter noted that, to implement this requirement, payers would need to develop an interface to move prior authorization data between multiple internal systems, which will be especially difficult for requests submitted in a non-electronic format. Other commenters noted business process and operational challenges that would make 1 business day difficult and burdensome, such as the time to manually assess whether they can legally make the information available via the Patient Access API under applicable state law. A commenter stated that 1 business day would not be feasible for Medicaid agencies due to the necessary updates to the Medicaid Management Information System (MMIS) systems.
                    </P>
                    <P>Many commenters recommended that CMS instead consider requiring a 2 business day response requirement. A commenter recommended extending the proposed requirement to 2 business days until electronic Prior Authorization APIs are widely adopted and proven, and only then consider a 1 business day requirement. Another commenter recommended that CMS extend the timeframe window to 7 calendar days. Some commenters noted that although the prior authorization process would be automated by the implementation of the Prior Authorization API, they recommend extending the 1 business day timeframe for the Patient Access API to match the period a payer has to make a determination on the prior authorization.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' perspectives regarding the feasibility of a 1 business day timeframe. Per the comments we received, the most significant barrier to the 1 business day timeframe we proposed was the proposed requirement to include unstructured documentation with prior authorization information. As discussed previously, we are not finalizing a requirement to make available unstructured prior authorization documentation via the Patient Access API. That exclusion from the data required to be made available will reduce the amount of data translation and transformation required to have data available via the Patient Access API. In addition, as discussed in section I.D., we are delaying the compliance 
                        <PRTPAGE P="8776"/>
                        dates by 1 year from our proposed 2026 to 2027 in order to give impacted payers additional time to make system changes necessary to meet the requirements of this final rule. We acknowledge that this may be particularly challenging for Medicaid and CHIP agencies based on existing MMIS systems. As discussed in section II.E. of this final rule, expenditures for required changes to states' MMIS or other state systems may be eligible for enhanced Federal financial participation. That funding may be available, not just for systems and processes that directly contribute to data available via the Patient Access API, but for other systems, such as those that track prior authorization requests and decisions. We also note that the Prior Authorization API discussed in section II.D. will greatly facilitate the movement of structured prior authorization data. Payers, including Medicaid and CHIP, should consider levers for promoting its usage by their providers.
                    </P>
                    <P>After reviewing comments, we believe that between the changes to the data that must be shared and the additional implementation time, payers will be able to make necessary changes to meet these requirements by the finalized compliance dates. Therefore, we are finalizing the timeframe as proposed and are requiring payers to make prior authorization information available via the Patient Access API within 1 business day of receiving a request. Impacted payers must update prior authorization information made available via the Patient Access API within 1 business day of any status change.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS retain the proposed 1 business day timeframe for prior authorization requests received via the Prior Authorization API but extend the timeframe for prior authorizations received through other channels (for example, by proprietary portal, fax, or phone). A commenter noted that, in the dental field, not all prior authorizations are submitted electronically. An additional commenter noted this timeframe does not provide impacted issuers adequate time to transfer information received by alternate methods (phone, fax) to interoperable, electronic formats. A commenter stated that the turnaround is not operationally feasible if the information is not received in a standardized format.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed in the previous section, we are finalizing our proposal with a modification to require that only structured documentation related to prior authorizations be made available via the Patient Access API. We believe this modification will, in large part, address this issue. Payers will not be required to convert documentation from non-electronic or non-standardized prior authorization requests into standardized data that can be available via the Patient Access API. However, by requiring only the structured data elements, including documentation, and not unstructured documents or images, we believe that this will streamline that conversion process and make the 1 business day timeline feasible for payers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS create flexibility for delays between a provider sending the request and the payer's receipt. Another commenter recommended that CMS finalize a policy that the 1 business day timeline for making prior authorization data available via the Patient Access API begins only once the payer has information adequate to adjudicate the prior authorization request, as defined by payers' prior authorization policies. The commenter noted that some payers may require additional time to gather the information and perform any necessary data transformation to the FHIR standards. Similarly, another commenter recommended that the 1 business day requirement only applies after a request is received via the X12 278 transaction standard or Prior Authorization API electronic transaction that passes validation. Another commenter recommended that CMS require information about prior authorization be made available no later than 1 business day after a payer makes a decision.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Our proposal was for the 1 business day timeframe to begin when the payer receives the prior authorization request. We are not requiring payers to share information that they do not possess. However, we disagree with the commenters' suggestions that the 1 business day timeline should begin when the payer has sufficient information to adjudicate a prior authorization request, or an adjudication has been made. A payer could not know whether there is sufficient information in the request to make a decision before the request is reviewed. As other commenters noted, it is critical that patients know that a payer has received the prior authorization request made on their behalf, even if it has not yet been reviewed or adjudicated. In section II.D., we are finalizing a policy that requires certain payers to make a decision within 7 calendar days for standard requests and 72 hours for expedited requests. It may take a payer several days to review a prior authorization request, and not having any status updates during that time would leave patients and providers in limbo.
                    </P>
                    <P>We did not propose and are not finalizing a requirement that the timeline for making data available only applies to prior authorization requests received via an electronic HIPAA-compliant X12 278 transaction and/or FHIR transaction. We know that payers currently support a variety of modalities for providers to submit prior authorization requests, including online portals, phone, and fax. We believe that patients should have access to their prior authorization data within the same timeframe, regardless of how the prior authorization request was submitted. Because we are not finalizing the requirement to include unstructured documentation, receiving documentation in an unstructured format as part of a request will not hamper or delay a payer's ability to make the required prior authorization data available through the Patient Access API. A HIPAA-compliant X12 278 transaction is, by definition, composed of structured data, which must be made available through the Patient Access API, though attachments to such a transaction are likely unstructured documentation. Finally, we note that if the payer receives a request that does not pass validation or cannot be processed for some other reason, this could be an acceptable status to provide. If a payer's system fails to receive such a request, we cannot expect the data to be made available via the Patient Access API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS require providers to respond to payers' requests for information within a certain timeframe and include information on provider response timeliness in the Patient Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose a timeline for providers to respond to payers' requests for additional information. However, it is entirely appropriate for a prior authorization status to be “waiting for additional information from provider” or similar. That would indicate to the patient that the provider must take some action to receive approval of the prior authorization, which would allow them to follow up with the provider to ensure that is done in a timely manner.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A couple of commenters requested clarification about the relationship between our Patient Access API requirements and ONC's information blocking regulations at 45 CFR part 171. Specifically, commenters questioned the implications of the 
                        <PRTPAGE P="8777"/>
                        information blocking regulations if payers also meet the definition of a health information network (HIN) or HIE at 45 CFR 171.102. They questioned whether our timeline requirement is compatible with the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” final rule (85 FR 25642) (ONC Cures Act final rule), which the commenter explained requires information to be made available to the patient “without delay.”
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Any impacted payer should consider reviewing the ONC Cures Act final rule to determine whether they are an actor (as defined at 45 CFR 171.102) and to ensure they are complying with any applicable information sharing policies. The information blocking regulations (45 CFR part 171) are based on separate statutory provisions (see 42 U.S.C. 300jj-52), unrelated to our authority to issue this rule. We encourage commenters to address questions or complaints regarding information blocking to ONC.
                        <SU>16</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             Office of the National Coordinator for Health Information Technology (2023, November 2). Information Blocking. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                        </P>
                    </FTNT>
                    <P>
                        We work closely with ONC and our other Federal partners to ensure that our regulations do not place conflicting requirements or unnecessary burdens on entities that are regulated by more than one Federal agency. However, comments specific to the information blocking regulations or other regulations issued by ONC are outside the scope of this rule. Additional information is available from the Information Blocking page of ONC's website: 
                        <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                    </P>
                    <HD SOURCE="HD3">iv. Length of Prior Authorization Data Availability</HD>
                    <P>We proposed to require that information about prior authorizations be available via the Patient Access API for as long as the authorization is active and at least 1 year after the last status change. We note that, under the proposal, information on denied and expired prior authorizations would be available for at least 1 year after expiring or being denied. We did not propose to require payers to share a patient's full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Claims, encounter, and clinical data can provide valuable information about a patient's health history. With those data available through the Patient Access API, we believe that process-related information about long-expired or denied prior authorizations will be irrelevant. Also, as payers' prior authorization policies may change over time, that information has a limited lifespan of usefulness to a patient's current care. At the same time, the API should include information about all active authorizations for as long as they are active, and, therefore, may include information related to ongoing care.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A majority of commenters supported CMS's proposal to require prior authorization information to be available via the Patient Access API for as long as the authorization is active and for 1 year after the last status change. Commenters opined that this timeframe balanced the benefits of data availability and the burden of maintaining data.
                    </P>
                    <P>Some commenters suggested that CMS require payers to make prior authorization information available through the Patient Access API for longer than 1 year after the last status change. For example, some commenters suggested 3 years and others 5 years as the appropriate period to make information available after the last status change. Other commenters recommended that CMS require payers to make all prior authorization information available via the Patient Access API until 1 year after the patient is no longer covered by that payer. Those commenters stated that historical prior authorization information may yet be relevant to a patient's care or could create a record for patients to demonstrate that they face repeated barriers in accessing care or receiving coverage. Finally, another commenter suggested that those data may be important for long-term treatment that exceeds 1 year.</P>
                    <P>
                        <E T="03">Response:</E>
                         We continue to believe that 1 year after the last status change is the appropriate amount of time to require payers to make historical prior authorization information available to patients through the Patient Access API. There may be other requirements outside the scope of this rulemaking that require certain payers to make health care records available to individuals over a longer time period. Further, this rulemaking does not address the record maintenance requirements that apply to impacted payers. We only address the timeframe during which certain data must be made available through specific APIs. While background information may impact and improve patient care, we believe that the availability of claims and clinical data are more important to patients and providers than information about prior authorizations that have expired or been denied. In fact, a patient's claims or encounter data are likely to include any items or services that were subject to a past prior authorization. As finalized in the CMS Interoperability and Patient Access final rule, and as modified by this final rule, payers are also required to make available through the Patient Access API any claims and encounter data, and all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), which includes clinical data, maintained by the impacted payer with a date of service on or after January 1, 2016.
                    </P>
                    <P>As discussed previously, some commenters stated that including prior authorization information in the Patient Access API could lead to information overload and confusion for patients. While we do not believe that to be the case for active and recent prior authorizations, it may be so if patients were presented with a large amount of historical prior authorization data that may no longer be relevant. Therefore, we believe that 1 year is the appropriate timeframe for requiring prior authorization data to be available via the Patient Access API. We emphasize that for ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than 1 year. Furthermore, we encourage payers to make these prior authorization data available for longer than 1 year if they believe it adds value to patients, providers, or themselves and their own processes.</P>
                    <HD SOURCE="HD3">b. Interaction With HIPAA Right of Access Provisions</HD>
                    <P>
                        Previous CMS interoperability proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule individual right of access.
                        <SU>17</SU>
                        <FTREF/>
                         Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of PHI about themselves in a designated record set for as long as the PHI is maintained in the designated record set by a covered entity. This includes the right to inspect or obtain a copy, or both, of the PHI. Our Patient Access API policies complement that right by requiring payers to make available—through a standards-based and interoperable FHIR API (that is, the Patient Access API)—PHI that patients already have a right to access. It is critical that individuals have access to their own health information and the ability to share it with others who are 
                        <PRTPAGE P="8778"/>
                        involved in their care, particularly when it could involve care coordination between providers or prior authorization.
                    </P>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             
                            <E T="03">See</E>
                             CMS Interoperability and Patient Access final rule (85 FR 25516-19) and December 2020 CMS Interoperability proposed rule (85 FR 82586).
                        </P>
                    </FTNT>
                    <P>Consistent with the HIPAA Privacy Rule, we believe that it behooves us to require all impacted payers to have the capability to provide individuals' PHI via an industry standard FHIR API, so that patients can access their data through apps of their choice. We believe that, in addition to the other benefits described in this final rule, ensuring that patients can receive their PHI in a standard, interoperable format that they can use with the latest technologies will reduce instances of an individual requesting PHI in an electronic format that is not readily producible, which could reduce costs and burden for patients and payers.</P>
                    <P>
                        In the CMS Interoperability and Patient Access final rule, we established that the only reason payers could deny API access to a patient's preferred health app is if it would present an unacceptable level of risk to the security of PHI on the payer's system. These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers.
                        <SU>18</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             See 42 CFR 422.119(e) for MA organizations; 42 CFR 431.60(e) for state Medicaid FFS programs, through the existing cross reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42 CFR 457.730(e) for state CHIP FFS programs, through the existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(e) for QHP issuers on the FFEs.
                        </P>
                    </FTNT>
                    <P>
                        As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25518), disagreement with the patient about the worthiness of a health app as a recipient of patient data, or even concerns about what the app might do with the requested data, are not acceptable reasons to deny an individual's request. Impacted payers may offer advice to patients on the potential risks of permitting an app or entity access to the patient data required to be made available via the Patient Access API. However, such efforts generally must stop at education and awareness or advice related to a specific app. Payers can inform the patient that the patient may not want to allow an app to access their data without a clear understanding of how that app may use their data, including how the patient's personal data would be used or sold (a possibility for apps that are not covered entities or business associates under the HIPAA Privacy Rule and the Security Standards for the Protection of Electronic Protected Health Information 
                        <SU>19</SU>
                        <FTREF/>
                         [the Security Rule]). For instance, if a payer learns that a particular app has publicly known privacy or security vulnerabilities, they could inform patients who use that app to access their data of those known vulnerabilities. Per our policies finalized in the CMS Interoperability and Patient Access final rule, if a patient still wants to use the app, or does not respond to the payer's warning, the impacted payer is required to share their data via the API, absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see the CMS Interoperability and Patient Access final rule at 85 FR 25550. Again, the finalized policies in this rule do not affect or alter any obligations under the HIPAA Privacy and Security Rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             See 
                            <E T="03">also</E>
                             the HIPAA Security Rule, 45 CFR parts 160 and 164, subparts A and C.
                        </P>
                    </FTNT>
                    <P>
                        While FHIR itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule, at 45 CFR parts 160 and 164, subparts A and C, for secure data exchange.
                        <SU>20</SU>
                        <FTREF/>
                         Furthermore, a covered entity is not liable for what happens to the PHI once the designated third party receives the information as directed by the individual.
                        <SU>21</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             Health Level Seven International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from 
                            <E T="03">http://www.hl7.org/Fhir/security.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             Office for Civil Rights (2020, January 31). What is the liability of a covered entity in responding to an individual's access request to send the individual's PHI to a third party? Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Our policies in this section address how an impacted payer must make patients' data available to them. However, we do not have the authority to regulate health apps that individuals may wish to use, or what those apps do with patient data. Regardless of whether the HIPAA Privacy and Security Rules apply to a health app, and even where they do not apply, other Federal laws such as the Federal Trade Commission (FTC) Act may apply. Under section 5 of the FTC Act (15 U.S.C. 45(a)), the FTC has authority to challenge unfair or deceptive trade practices, including those related to the privacy and security of personal health information that apps collect, use, maintain, or share. For example, if an app discloses an individual's health information in a manner inconsistent with the app's privacy policy, terms of use, or an individual's reasonable expectations, or fails to take reasonable measures to assess and address privacy or data security risks, the developer of that app may be violating the FTC Act. The FTC has applied its section 5 authority to a wide variety of entities, including health apps.
                        <SU>22</SU>
                        <FTREF/>
                         For more information about what laws may apply to health apps, see 
                        <E T="03">https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.</E>
                    </P>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             
                            <E T="03">See U.S.</E>
                             v. 
                            <E T="03">Easy Healthcare Corp.,</E>
                             Case No. 1:23-cv-3107 (N.D. Ill. 2023), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; In the Matter of BetterHelp, Inc.,</E>
                             FTC Dkt. No. C-4796 (July 14, 2023), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-betterhelp-inc-matter; U.S.</E>
                             v. 
                            <E T="03">GoodRx Holdings, Inc.,</E>
                             Case No. 23-cv-460 (N.D. Cal. 2023), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc; In the Matter of Flo Health Inc.,</E>
                             FTC Dkt. No. C-4747 (June 22, 2021), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc.</E>
                        </P>
                    </FTNT>
                    <P>
                        The FTC also enforces the FTC Health Breach Notification Rule (16 CFR part 318), which applies to most health apps and similar technologies that are not covered entities or business associates under HIPAA and, therefore, are not subject to the HIPAA Breach Notification Rule (45 CFR 164.400 through 164.414).
                        <SU>23</SU>
                        <FTREF/>
                         The FTC's Health Breach Notification Rule sets forth steps that entities covered by that rule must follow when there has been a breach of unsecured personal health information. Any violation of the FTC's Health Breach Notification Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and is subject to civil penalties of up to $50,120 per violation per day.
                        <SU>24</SU>
                        <FTREF/>
                         In 2023, the Commission brought its first enforcement actions under the Health Breach Notification Rule.
                        <SU>25</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             Federal Trade Commission (January 2022). Complying with FTC's Health Breach Notification Rule. Retrieved from 
                            <E T="03">https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule.</E>
                             See also Federal Trade Commission (2021, September 15). Statement of the Commission on Breaches by Health Apps and Other Connected Devices. Retrieved from 
                            <E T="03">https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             16 CFR 1.98 makes inflation adjustments in the dollar amounts of civil monetary penalties provided by law within the Commission's jurisdiction.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             
                            <E T="03">See U.S.</E>
                             v. 
                            <E T="03">Easy Healthcare Corp.,</E>
                             Case No. 1:23-cv-3107 (N.D. Ill. 2023), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; U.S.</E>
                             v. 
                            <E T="03">GoodRx Holdings, Inc.,</E>
                             Case No. 23-cv-460 (N.D. Cal. 2023), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="8779"/>
                    <HD SOURCE="HD3">c. Patient Access API Metrics</HD>
                    <P>We proposed to require impacted payers to report metrics to CMS on an annual basis about how patients use the Patient Access API, in the form of aggregated, de-identified data. We stated that those reports would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Additionally, we stated that aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. We also stated that gathering this information would help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types.</P>
                    <P>Specifically, we proposed that impacted payers annually report—</P>
                    <P>• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and</P>
                    <P>• The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.</P>
                    <P>Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or allowing apps to update their information over the course of the year. While data transfers may not indicate to what extent patients are using apps to manage their health care, it would be a preliminary indicator of interest in the technology.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A majority of commenters supported CMS's proposal to require impacted payers to report aggregated, de-identified data metrics on how patients use the Patient Access API to CMS annually.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their feedback.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters recommended that these metrics only be used to evaluate the effectiveness of CMS's policies and to assess whether patients are using the Patient Access API in a volume sufficient to justify the administrative burden of existing and future requirements. A commenter stated that these metrics would not reflect factors within a payer's control and recommended that CMS work with FTC to have third-party app developers directly report these metrics. Another commenter warned that these metrics may not account for patient preferences for portals or other resources aside from apps. A commenter recommended that neither CMS nor state Medicaid agencies attempt to regulate or oversee the usage of third-party apps by their users. Another commenter supported the annual public reporting of Patient Access API metrics provided that this information is not made publicly available in a manner that identifies specific payers or apps.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that patient app usage is generally outside the control of payers, though education can help patients make informed decisions. We emphasize that we proposed and will be collecting these metrics, not to evaluate or compare payers, but to help us understand how patients are using apps, the effectiveness of our Patient Access API policies, and to assess potential future rulemaking.
                    </P>
                    <P>Making data available via a FHIR API gives patients a wider range of options to access their data. Ultimately, patients must decide what method of accessing their health information is most useful to them. If patients prefer to use online portals, rather than apps, that could inform future rulemaking. However, to understand how patients are accessing data made available through the API using a heath app designated by the patient, we must have access to the relevant data. We do not intend to interfere with how a patient uses a third-party app (and neither should impacted payers, including state Medicaid agencies), but to provide them options to access their data in the way that best suits them. As discussed previously, the only permissible reason to deny or discontinue an app's access to an API is if the payer reasonably determines that the app presents an unacceptable level of risk to the security of PHI on the payer's systems.</P>
                    <P>We do not have the authority to require app developers to report usage metrics, and even if we did collect data from them, it would not provide the information that we are seeking, as developers would not know a patient's health coverage status. For instance, a developer could tell us that an individual connected to a specific payer organization but would not be able to report whether the patient is covered under by an MA plan or QHP. Finally, as noted in the proposed rule, we do not intend to publicly publish these Patient Access metrics in a way that identifies specific payers or apps.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters suggested that CMS establish an easy-to-use standardized format for reporting Patient Access API metrics.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the request from commenters and are finalizing a modification to our proposed regulatory text to require reporting in a specified form and manner to ensure consistency between impacted payers. We will issue specific format and process guidance for submitting Patient Access API metrics before reporting is required.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Most commenters supported CMS's proposed metrics, as they could provide valuable information regarding Patient Access API adoption and use.
                    </P>
                    <P>Commenters voiced widespread support for the first metric to measure usage of the Patient Access API. Support for the second metric was mixed, with multiple commenters questioning its value to the API's policy evaluation. Commenters warned that this metric would be affected by many external factors, including the user experience of the app, as opposed to acts of the payer. Another commenter stated that the second measure would not provide meaningful insight into patient use patterns, and instead suggested that CMS should solicit information about usage patterns from app developers.</P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that the metric on repeat usage may not provide a high level of statistical validity, which is why we are not requiring these metrics to be reported publicly. However, it is important for CMS to understand how many patients are using the Patient Access API and whether they have simply tried it once or are invested in using health apps to manage their data. These findings will help us monitor our interoperability policies and plan for the future. We did not receive any comments that indicated that submitting either of these metrics would be a significant burden for impacted payers.
                    </P>
                    <P>We acknowledge that these metrics could be affected by a plethora of external factors outside of payers' control. As noted previously, we are collecting these metrics to better enable us to evaluate our policies in this area. As we do not have regulatory authority over app developers, we did not propose to impose reporting requirements on them.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS explain what constitutes a “unique patient” so that payers can identify unique patients in the same manner, so the results are not varied.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We define a unique patient by the record of the individual covered by the payer's benefits, not by the individual accessing the data. Therefore, if both a patient and their personal representative access their data, that will only be counted as usage by a 
                        <PRTPAGE P="8780"/>
                        single patient for the purpose of these metrics.
                    </P>
                    <HD SOURCE="HD3">i. Reporting Level</HD>
                    <P>We proposed to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We solicited comment on whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also solicited comment on an alternative final policy that would permit MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data at higher levels (such as the parent organization level or all plans of the same type in a program).</P>
                    <P>
                        <E T="03">Comment:</E>
                         We received comments espousing a range of opinions on the appropriate level of reporting for impacted payers.
                    </P>
                    <P>Specifically for MA organizations, multiple commenters recommended a more granular metric reporting level, noting that reporting Patient Access API metrics at the plan level would better drive plan-specific improvement efforts and be more consistent with current industry practice. Conversely, a commenter stated that organization level would simplify report preparation since some MA organizations have ten or more separate plan contracts with CMS. A commenter recommended that CMS not require reporting at the more granular contract level as any metrics based on small populations could lead to skewed data.</P>
                    <P>Many commenters supported our proposed reporting levels for Patient Access API use metrics for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.</P>
                    <P>On the other hand, a commenter recommended that payers be required to report metrics at the county level, rather than the state level. Another commenter warned that too much aggregation can make data meaningless and stated that payers should prioritize data metrics that can be acted upon effectively. Conversely, a commenter recommended that CMS allow consolidation of Patient Access API use metrics at the holding or parent company level, which would aggregate that company's MA plans, Medicaid managed care plans, CHIP managed care entities, QHPs, and commercial plans. Another commenter suggested that CMS begin collecting metrics at a more aggregated level and wait to implement more refined data segmentation as a clear use case arises.</P>
                    <P>
                        <E T="03">Response:</E>
                         Upon further consideration, we determined that contract level is the more appropriate reporting level for MA organizations. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) offered under an individual contract; it is specific to the contract to which it corresponds. CMS already requires MA organizations to annually report some contract-level data about their organization determinations to the agency. A consistent approach of contract-level reporting in the MA program will give us useful information while limiting payer burden. By requiring contract-level reporting for these metrics, we ensure that the format of these reported data remain consistent with other data that MA organizations are required to report. There could be value to requiring MA organizations to report on a plan level in the future to get more discrete data. However, at this time, we believe that the burden of requiring MA organizations to report at the plan level, and the small sample sizes that some plans would have, outweigh the benefits of that information.
                    </P>
                    <P>We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the state level and QHP issuers on the FFEs to report at the issuer level balances the reporting burden and the meaningfulness of the data. Aggregating by holding company would provide data that are not particularly useful. Many commenters recommended that we use this information to monitor disparities in data access, which would be hindered without disaggregation between MA, Medicaid, CHIP, and QHPs. Similarly, we do not believe that additionally segmenting data into smaller geographic areas would provide useful information now, though in the future we may consider whether it would be beneficial.</P>
                    <P>We note that CMS programs may assess whether to collect more detailed metrics than we are finalizing here. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial, they may require additional metrics in their managed care contracts.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters requested that we explain whether integrated care plans for dually eligible individuals, such as fully integrated dual eligible special needs plans (FIDE SNPs), should report consistent with MA organizations, at the contract level, or with Medicaid managed care plans, at the plan level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         An integrated care plan generally combines a dual eligible special needs plan (D-SNP), which includes FIDE SNPs and highly integrated dual eligible special needs plans (HIDE SNPs)—both as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by the same parent organization. D-SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. Therefore, an MA organization will report information about Patient Access API usage by its D-SNP enrollees to CMS at the MA organization's contract level. The affiliated Medicaid managed care plan will report information about Patient Access API usage by its enrollees to CMS at the plan level.
                    </P>
                    <P>We understand that this means an organization that offers an integrated product for dually eligible individuals (for example, a FIDE SNP), may report twice and in different ways for the same population. We do not believe this duplication outweighs the benefits of capturing the data as we proposed, but we may consider future rulemaking to separate reporting for integrated D-SNPs from the overall MA organization.</P>
                    <HD SOURCE="HD3">ii. Annual Reporting</HD>
                    <P>We proposed that payers must report metrics from the previous calendar year to CMS by March 31st of each year. Under our proposal, in the first year the requirement would be applicable, payers would report CY 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposal to require payers to share patient use metrics annually starting with CY 2025 to be reported to CMS by March 31, 2026. Some commenters recommended that we delay the first year of the reporting requirement to CY 2026, which would be reported no later than March 31, 2027. Another commenter suggested that we delay the reporting deadline because a technical solution would need to be in place by the end of late 2024 to have metrics for CY 2025 to report in March 2026.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that per the CMS Interoperability and Patient Access final rule, impacted payers were required to 
                        <PRTPAGE P="8781"/>
                        implement the Patient Access API no later than January 1, 2021. The metrics that we proposed were not tied to the implementation of any other proposals in the CMS Interoperability and Prior Authorization proposed rule, including adding prior authorization information to the data available via the Patient Access API. Based on this rule's publication schedule, payers should have sufficient time to implement any necessary changes to report these metrics.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A majority of commenters supported the proposed annual reporting requirement, though multiple commenters recommended that CMS consider requiring payers to report Patient Access API metrics quarterly. A commenter recommended that as the popularity for Patient Access API grows, use metrics should be reported on a quarterly basis.
                    </P>
                    <P>Commenters agreed that requiring payers to report data on API usage from the previous calendar year to CMS by March 31 provides an appropriate amount of time for payers to validate the data before submitting it to CMS.</P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing the comments, we agree that annual reporting is the appropriate frequency for these metrics. Given that we are looking to understand the overall usage of third-party apps and any patterns between payers, we do not believe that the burden of requiring payers to report these metrics quarterly would improve our understanding of whether patients are accessing the Patient Access API. We may in the future consider proposing more frequent reporting or additional metrics, but for the two metrics we are finalizing now, we do not expect that it would be beneficial to require payers to report more often than annually.
                    </P>
                    <HD SOURCE="HD3">iii. Public Reporting</HD>
                    <P>In the preamble to our proposed rule, we stated that we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and de-identified data that do not include names of specific state agencies, plans, or issuers.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that CMS require payers to publicly report Patient Access API metrics, as they believe that health IT companies and developers would benefit from the information. Commenters stated that by making these metrics public, CMS can help patients and stakeholders better understand the impact of access APIs and help inform future innovations that promote patient access and future decision making. A commenter recommended that CMS consider publicly reporting plan-reported information at the state, plan, or issuer level.
                    </P>
                    <P>Other commenters did not support CMS publicly reporting Patient Access API use metrics. Multiple commenters stated that this could provide inaccurate information and potentially reveal identifying information. A commenter cautioned that publicizing reports, particularly of the second proposed metric (the total number of patients whose data are transferred more than once to a specific third-party app), may give consumers an inaccurate portrayal of API success.</P>
                    <P>
                        <E T="03">Response:</E>
                         There may be value to publicly reporting aggregated and de-identified data to give the public a sense of Patient Access API adoption across the industry. But we agree with commenters that, absent the proper context, those data could be perceived inaccurately or misleadingly. As discussed, some commenters expressed that there is currently low health app adoption among patients regardless of the type of payer. We also understand that low patient adoption does not necessarily indicate a lack of payer readiness or compliance. Therefore, until we are confident that these data can be presented in an easy-to-understand and meaningful way, we may publicly report aggregated and de-identified data, but will not include names of specific state agencies, plans, or issuers unless and until proposed through future rulemaking.
                    </P>
                    <HD SOURCE="HD3">iv. Other Metrics</HD>
                    <P>We requested comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public in future rulemaking. For instance, we solicited comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographic data and whether that could help identify underserved populations or disparities in patient access to health data and, if so, policies that should be considered to promote equity. We also solicited comments on the potential benefits and burdens of requiring payers to report the names of all apps that patients have used to access the payers' API each year. We considered collecting this information, or requiring payers to make it public, not for the purpose of recommending or endorsing specific apps, but to review for best practices and evaluate patient ease of use.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters provided many recommendations for additional Patient Access API metrics.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We greatly appreciate the wide range of metric suggestions, such as indicators on demographic information, utilization, query management, successful requests, and barriers to accessing records. We will continue to research additional ways to evaluate the effectiveness of the API for consideration in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">d. Patient Access API Amendments</HD>
                    <P>We proposed two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). Unlike most of our proposals, we proposed that these amendments would take effect on the effective date of the final rule. We proposed these changes to explain terms but did not expect them to substantively change any current regulatory obligation.</P>
                    <P>First, we proposed to revise the description of the clinical data impacted payers must make available via the Patient Access API. These provisions, finalized in the CMS Interoperability and Patient Access final rule, currently require payers to make available “clinical data, including laboratory results” (85 FR 25536-40). We proposed to revise these paragraphs to specify that the data that payers must make available are “all data classes and data elements included in a content standard at 45 CFR 170.213.” That citation is to a content standard maintained by ONC of clinical data classes and data elements for interoperable health information exchange. Referring explicitly in the rule text to a data set in a standard at 45 CFR 170.213 will help avoid unnecessary confusion, as this reference will more clearly identify exactly what data must be available through the Patient Access API. Furthermore, this change brings us into greater alignment with the standards promulgated by ONC and used by certified health IT developers.</P>
                    <P>
                        As versions of the USCDI evolve, there may simultaneously be multiple versions of the standard referenced at 45 CFR 170.213 (as both v1 and v3 are listed at the time of publication of this final rule). In the HTI-1 final rule, ONC finalized the adoption of USCDI v3 in 170.213 and finalized a January 1, 2026, expiration date for USCDI v1 (89 FR 1192). For the ONC Health IT Certification Program, this allows for a transition period between standards, and, during that time, health IT developers could incorporate updated standards versions within their systems and complete required certification. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be 
                        <PRTPAGE P="8782"/>
                        allowed to use any of the then-referenced content standards to meet the requirement to make clinical data available through the Patient Access API. If a standard has a listed expiration date (as USCDI v1 is currently listed to expire on January 1, 2026), payers would not be able to be use it after expiration.
                    </P>
                    <P>Second, we proposed to revise the language previously finalized for denial or discontinuation of a health app's access to the API. Currently, the rules require impacted payers to make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which “enrollees” or “beneficiaries” seek to access patient data. We proposed to change the terms “enrollees” and “beneficiaries” to “parties” for consistency with our proposal to apply this provision to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We stated that because parties other than patients, such as providers and payers, would be accessing these APIs, it would be more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.” Those APIs are discussed further in sections II.B., II.C., and II.D. of this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         All comments we received on these technical language proposals supported our effort to keep the Patient Access API required data aligned with ONC's standards. However, we did receive a variety of comments on the USCDI standard currently referenced at 45 CFR 170.213. Those comments are discussed in section II.G. of this final rule.
                    </P>
                    <P>A commenter requested clarification on whether payers would be required to request information from providers to fill any data classes and data elements of the standard at 45 CFR 170.213 that are missing within their records. Similarly, another commenter requested that CMS explain that the requirement to provide claims and encounter data within 1 business day applies only to information available at the time of the request.</P>
                    <P>
                        <E T="03">Response:</E>
                         In the CMS Interoperability and Patient Access final rule, we defined “maintain” to mean the payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538). Under that existing regulation, payers are required to share data that they maintain as part of their normal operations. Nothing in this final rule will change that existing policy; payers are not required to reach out to providers or other entities to gather data that the payer does not already maintain, if it is not part of their normal operations, to share via the Patient Access API. We thank commenters for their feedback and are finalizing this proposal without modification.
                    </P>
                    <P>We note that we are not modifying the Patient Access API applicability date for MA at 42 CFR 422.119(h), for Medicaid FFS at 42 CFR 431.60(h), for CHIP FFS at 42 CFR 457.730(h), and for QHP issuers on the FFEs at 45 CFR 156.221(i) because these amendments do not substantively change any existing requirements finalized in the CMS Interoperability and Patient Access final rule.</P>
                    <HD SOURCE="HD3">e. Medicaid Expansion CHIP Programs</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we discussed implementation for states with Medicaid Expansion CHIP programs (86 FR 76279). See section II.E. of this final rule for that complete discussion, including a summary of public comments received and our final action statement.</P>
                    <HD SOURCE="HD3">f. Specific CHIP-Related Regulatory Framework</HD>
                    <P>For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would align separate CHIP managed care API requirements with the Medicaid managed care plan API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled “Medicaid Program; Medicaid and Children's Health Insurance Program (CHIP) Managed Care” (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We apply the API requirements in this final rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242.</P>
                    <HD SOURCE="HD3">3. Other Requests for Comment</HD>
                    <P>We requested comment on a variety of topics on which we did not make specific proposals but are reviewing for future consideration. We appreciate commenters' submissions regarding the following:</P>
                    <P>• How we could and should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards.</P>
                    <P>• What policy levers we might have to create norms or best practices for privacy policies by health app developers.</P>
                    <P>• How we could leverage ONC's TEFCA or other HHS HIE initiatives to facilitate secure interoperable data exchange with health apps.</P>
                    <P>• The availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at appropriate literacy levels and in plain language.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8783"/>
                        <GID>ER08FE24.000</GID>
                    </GPH>
                    <PRTPAGE P="8784"/>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <HD SOURCE="HD3">4. Final Action</HD>
                    <P>After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications:</P>
                    <P>• Impacted payers must make information about prior authorization requests and decisions available via the Patient Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), rather than in 2026.</P>
                    <P>• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Patient Access API.</P>
                    <P>• Impacted payers are not required to share unstructured documentation related to prior authorizations via the Patient Access API.</P>
                    <P>• MA organizations must report Patient Access API metrics at the contract level rather than at the proposed organizational level.</P>
                    <P>See further discussion for exact details of the final requirements for impacted payers.</P>
                    <P>Specifically, we are finalizing a requirement that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must make the all of following information available about prior authorization requests and decisions (excluding for drugs) available via the Patient Access API:</P>
                    <P>• The prior authorization status.</P>
                    <P>• The date the prior authorization was approved or denied.</P>
                    <P>• The date or circumstance under which the prior authorization ends.</P>
                    <P>• The items and services approved.</P>
                    <P>• If denied, a specific reason why the request was denied.</P>
                    <P>• Related structured administrative and clinical documentation submitted by a provider.</P>
                    <P>We are finalizing the requirement that impacted payers make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.</P>
                    <P>We are finalizing a requirement that, beginning 2026, impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data. Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must report the following metrics: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Impacted payers must report the previous calendar year's metrics to CMS by March 31 following any year that they offered that type of plan.</P>
                    <P>We are finalizing, as of the effective date of this final rule, the replacement of “clinical data, including laboratory results” with “all data classes and data elements included in a content standard at 45 CFR 170.213” in the required content for the Patient Access API. We are also finalizing, as of the effective date of this final rule, to change the terms “enrollees” and “beneficiaries” to “parties” at 42 CFR 422.119, 431.60, and 438.62 and 45 CFR 156.221.</P>
                    <P>These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table B1.</P>
                    <HD SOURCE="HD3">5. Statutory Authorities for the Patient Access API Policies</HD>
                    <P>We note that we received no public comments on the statutory authorities for our Patient Access API policies.</P>
                    <HD SOURCE="HD3">a. MA Organizations</HD>
                    <P>For MA organizations, we proposed these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) of the Act (to promulgate regulations implementing MA organization standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be “necessary and appropriate”). Section 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our policy for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The policies here meet this standard by addressing and facilitating access to enrollees' medical records and health information for the reasons identified in our discussions for each policy.</P>
                    <P>The policy in section II.A.2.a. of this final rule that will require MA organizations to make an enrollee's prior authorization requests and related clinical documentation available through the Patient Access API will allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees' best interests. This requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes.</P>
                    <P>
                        Making this information available via the Patient Access API could help patients support the prior authorization 
                        <PRTPAGE P="8785"/>
                        process as well. Patients could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Patients could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee's experience with the process, by facilitating more timely and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services.
                    </P>
                    <P>In addition, to ensure the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS finalized in this rule that MA organizations report specific metrics to CMS on patient use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these metrics would facilitate CMS's oversight, evaluation, and administration of patient health data access in the Part C program and, therefore, this data collection is necessary and appropriate to adopt.</P>
                    <P>In alignment with HHS's priorities and goals, CMS is focused on putting patients at the center of their own health care and ensuring that patients have secure access to their health information. We believe these policies are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience.</P>
                    <HD SOURCE="HD3">b. Medicaid and CHIP</HD>
                    <P>Our finalized requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with simplicity of administration and the best interests of the recipients.</P>
                    <P>In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306.</P>
                    <P>Our policy to require that the prior authorization data described in this section be shared via the Patient Access API would be consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The data sharing policy for the Patient Access API would be related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history).</P>
                    <P>The finalized requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from state Medicaid FFS programs and Medicaid managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations. This would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these policies are authorized under section 1902(a)(4), (8), and (19) of the Act.</P>
                    <P>Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the finalized Patient Access API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this policy, because any request for beneficiary information would be from Medicaid beneficiaries themselves and the apps that they are authorizing to receive their information. Beneficiaries are not “outside sources,” and, while apps might be outside sources, information is shared with an app through this API only if the beneficiary has verified their identity (through authentication protocols) and authorized the app to receive information. We do not believe that any of the other requirements at 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our policies in this section of the final rule. We note that while the beneficiary's permission is not required under 42 CFR 431.306(d) for the Patient Access API we discuss here, state or other laws may require such permission.</P>
                    <P>
                        With respect to Medicaid managed care, and in addition to the general authorities cited previously mentioned regarding Medicaid programs, this policy will also help implement section 1932(b)(4) of the Act, which provides that each Medicaid MCO must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to 
                        <PRTPAGE P="8786"/>
                        Medicaid MCOs to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care.
                    </P>
                    <P>We also proposed to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. These metrics will support CMS's oversight, evaluation, and administration of the Medicaid program, as it will allow us to evaluate beneficiary access to the Patient Access API. API usage could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time require. These metrics will serve as a report to evaluate the implementation and execution of the Patient Access API.</P>
                    <P>For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the finalized requirements increase patient access to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across various sources of health benefits coverage.</P>
                    <P>We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries' prior authorization data and other standardized data available through standards-based APIs will lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access will help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We believe making patient data available in this format will result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including CHIP.</P>
                    <P>These policies align with section 2101(a) of the Act in that they also will improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API will allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This will in turn allow patients to make scheduling decisions and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, streamlining the prior authorization process.</P>
                    <P>Additionally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.</P>
                    <P>Finally, by finalizing the requirement for state CHIP agencies and CHIP managed care entities to report Patient Access API metrics to CMS annually will help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, which is an indication of the API's uptake among patients, including how many only use it for a one-time setup consistent with 2107(b)(1) of the Act. The more we understand about the Patient Access API's usage, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests.</P>
                    <HD SOURCE="HD3">c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>For QHP issuers on the FFEs, we finalized these new requirements under our authority at section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act) which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.</P>
                    <P>We believe generally that certifying only health plans that take steps to make enrollees' prior authorization requests and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in enrollees' best interests. Adding information about prior authorization requests to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests and would also facilitate more timely and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE-FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs.</P>
                    <P>
                        Finally, requiring QHP issuers on the FFEs to report Patient Access API metrics to CMS annually will help CMS assess the effect this API is having on enrollees and will inform how CMS could either enhance the policy or improve access or use through activities 
                        <PRTPAGE P="8787"/>
                        such as additional patient education. These data could help CMS understand how best to leverage this API, and patient access to it, and to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the intended efficiencies.
                    </P>
                    <HD SOURCE="HD2">B. Provider Access API</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>In the CMS Interoperability and Patient Access final rule, we required impacted payers to implement a Patient Access API (85 FR 25558) that allows patients to access their health information through a third-party app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API, to inform the discussion with their provider.</P>
                    <P>In the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we had sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers, would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage a patient's care and providers could reduce or eliminate duplicate tests. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. In the final rule, we specifically agreed with commenters that making available information about prior authorization decisions via an API would reduce burden on providers and their staff (85 FR 25541). We also discussed the potential benefits of payers sharing patient health information directly with providers (85 FR 25555) and encouraged payers to consider an API solution that would enable direct provider access to appropriate health information to support the delivery of care.</P>
                    <P>While the Patient Access API was a significant first step toward sharing individual patient health information with providers, we believe it would benefit patients if payers were required to make patient data directly available to providers via a FHIR API. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in the CMS Interoperability and Prior Authorization proposed rule, we proposed to require impacted payers to implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security.</P>
                    <P>We also proposed a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API. Finally, we proposed Provider Access API compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).</P>
                    <P>As mentioned in section I.A. of this final rule, these policies do not pertain to Medicare FFS. In the proposed rule, we solicited comment on whether our Provider Access API proposal could be implemented in the Medicare FFS program. We expect that a Medicare FFS implementation would generally conform to the same requirements that apply to the impacted payers under this final rule, so Medicare FFS providers and beneficiaries enrolled in Medicare FFS could also benefit from this type of data sharing. We solicited comment on whether these requirements could be implemented as proposed, how we could apply each of these proposals, and if there would be any differences implementing the Provider Access API for the Medicare FFS program as a Federal payer. CMS's Data at the Point of Care (DPC) project is currently piloting an API that makes Medicare FFS claims and Part D data available to certain providers. However, some differences exist for Medicare FFS. For instance, provider remittances and patient cost-sharing information are not proprietary, so those data are shared in the DPC pilot; however, we proposed that impacted payers would not be required to share that information under our policies. Because the DPC API currently enables provider access to patient data and involves processes like authenticating the provider and verifying a patient treatment relationship with an attribution process, the information gained from the DPC pilot will be useful to impacted payers as we finalize proposals in this rule.</P>
                    <HD SOURCE="HD3">2. Requirements for Payers: Provider Access API for Individual Patient Information</HD>
                    <P>
                        In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available through a Patient Access API when requested by a patient. We stated that it would be valuable for providers to have access to the same patient data, except for provider remittances and patient cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing them with further insight into the patient's health care. Research shows that patients achieve better outcomes when their record is more complete, and more data are available to the health care provider at the point of care.
                        <SU>26</SU>
                        <FTREF/>
                         Making more comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data at the point of care could also reduce the burden on patients to recall and relay information during an appointment and/or provide confirmation that the patient's recollection of prior care is accurate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2019, June 4). Improved Diagnostics &amp; Patient Outcomes. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.</E>
                        </P>
                    </FTNT>
                    <P>Therefore, we proposed to require impacted payers to implement and maintain a Provider Access API to make current patients' information available to in-network or enrolled (as applicable) providers, at the provider's request. Under our proposal, an in-network provider is any provider or health care facility that is part of a specific health plan's network of providers with which it has a contract to furnish covered items or services. In the case of state Medicaid and CHIP FFS programs, that means any providers or health care facilities that are enrolled with the state as Medicaid or CHIP providers. We noted that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under our proposed policy.</P>
                    <P>
                        We explained that the Provider Access API would allow a provider to initiate a request when the provider needs access to a patient's data, such as prior to or during a patient visit. Both the Provider Access and Patient Access 
                        <PRTPAGE P="8788"/>
                        APIs would facilitate the FHIR-based exchange of claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer.
                    </P>
                    <P>We also stated that we believed that sharing claims and encounter data (without provider remittances and patient cost-sharing information) would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) by providing more information to support treatment and care coordination. Claims and encounter data, used in conjunction with clinical and other available data, can offer a broader, more complete picture of an individual's interactions with all their providers in the health care system. With that proposal, we intended to help providers gain efficient access to more comprehensive data on their patients. Specifically, we proposed to require impacted payers to make available any of the applicable patient data with a date of service on or after January 1, 2016, that they maintain. This timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available the same set of data from this timeframe via a FHIR API.</P>
                    <P>Finally, we explained that, unlike the Patient Access API, the Provider Access API would not include provider remittances and patient cost-sharing information. Many payers consider cost-sharing information proprietary and, while we do not necessarily agree with such a characterization, we believed that information would have limited benefit for treatment or care coordination and thus excluded it from the scope of data required to be accessible through the Provider Access API.</P>
                    <P>We proposed that payers would be required to make available via the Patient Access and Provider Access APIs information related to prior authorization requests and decisions for items and services (excluding drugs). This information would include, as applicable:</P>
                    <P>• The prior authorization status.</P>
                    <P>• The date the prior authorization was approved or denied.</P>
                    <P>• The date or circumstance under which the prior authorization ends.</P>
                    <P>• The items and services approved;</P>
                    <P>• If denied, a specific reason why the request was denied.</P>
                    <P>• Related structured administrative and clinical documentation submitted by a provider.</P>
                    <P>We proposed that information about prior authorizations be available via the Patient Access API for as long as the authorization is active, and for at least 1 year after the last status change, and that this would apply to the Provider Access API, as well. We noted in the proposed rule that this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We did not propose to require payers to share a patient's full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant.</P>
                    <P>In general, our proposal for the data that payers would have to make available through the Provider Access API, as well as the technical specifications, aligned with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and those that were proposed for the Patient Access API in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238).</P>
                    <P>However, we further explained that there are a few notable differences between the requirements for a Patient Access API and those for a Provider Access API. The biggest difference is how and why the end user will access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use, and potentially to share the data with a provider. For the Provider Access API, we expect that a provider will request and receive access to the patient's information through their EHR, practice management system, or other technology for treatment purposes. Providers will securely access their patients' data through a FHIR API using at least one of these systems. Providers will not access patient data through their own health app; rather, the data will flow from the payer to the provider's EHR or practice management system, which will allow them to incorporate the patient data into their records, should they choose to do so. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient's record in their own systems. Under this proposal, the provider would be able to request the additional data from the patient's payer. The payer would then be required to share the requested data no later than 1 business day after receiving a request from a provider who meets all other requirements to access the data.</P>
                    <P>In the CMS Interoperability and Patient Access final rule we required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). We proposed to require certain standards at 45 CFR 170.215 that are applicable to the Provider Access API. We are finalizing our proposals for the Provider Access API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). We are also recommending payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Provider Access API.</P>
                    <P>For Medicaid and CHIP managed care, we proposed that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. As proposed at 42 CFR 438.242(b)(7) and by cross-reference at 42 CFR 457.1233(d), all other Medicaid managed care plans and CHIP managed care entities (that is, MCOs, PIHPs, and non-NEMT PAHPs) would be subject to this final rule. We stated our belief that the unique nature and limited scope of the services provided by NEMT PAHPs, which only cover transportation and not medical care itself, justified their exclusion from the requirements of the Provider Access API. Specifically, we did not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API (and a Payer-to-Payer API, as discussed in section II.C.3. of this final rule) would be an undue burden. However, we did propose that NEMT PAHPs be subject to the requirements for the Patient Access API, Prior Authorization API, and prior authorization processes.</P>
                    <P>
                        We acknowledged that it could be helpful for all providers to have access to their patients' data regardless of contractual or enrollment relationships 
                        <PRTPAGE P="8789"/>
                        with a patient's payer. However, we proposed to only require impacted payers to share data with in-network or enrolled providers. We recognized that this could make it more difficult for an out-of-network provider to create or access a more comprehensive care record for a patient. We considered requiring payers to make the data available to all providers, regardless of whether the provider is under contract or enrolled with the payer. We will continue to consider a requirement to share patient data with out-of-network providers for future rulemaking. To this end, we requested comment in the proposed rule on existing processes for sharing data with out-of-network providers. Though we did not propose to require it, we encouraged payers to share information via API with out-of-network or unenrolled providers to the extent permitted by law if they can verify a treatment relationship. For state Medicaid and CHIP FFS programs specifically, data sharing with out-of-network and unenrolled providers would need to comply with Medicaid confidentiality rules as required by section 1902(a)(7) of the Act and implemented in our regulations at 42 CFR part 431, subpart F.
                    </P>
                    <P>We are finalizing our proposal to require impacted payers to make available to providers, via the Provider Access API, claims and encounter data (without provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorizations (excluding those for drugs). However, as with the Patient Access API policies, we are finalizing a modification to our proposal and not requiring payers to share the quantity of items or services used under a prior authorization or unstructured documentation related to a prior authorization. We are finalizing these changes to the Provider Access API policy with compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year after the proposed 2026 compliance dates. Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers.</P>
                    <P>
                        To support the Provider Access API implementation and maintenance, we are requiring certain standards and recommending certain IGs, as further discussed later and in section II.G. of this final rule. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there, are discussed further in section II.G. and reflected throughout this final rule. For the Provider Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program.
                        <SU>27</SU>
                        <FTREF/>
                         We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2023, September 11). 
                            <E T="03">Standards Version Advancement Process (SVAP).</E>
                             Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. General Comments</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported CMS's proposal to require impacted payers to develop and maintain a Provider Access API and recommended that CMS finalize the proposal. Multiple commenters also noted that the API would give health care providers invaluable insights into patient care, which could lead to better quality care, reduce duplicate services, and streamline provider workflows. A commenter recommended that CMS focus its efforts on the secure exchange of data from patients to providers via the Patient Access API, which could allow the patient to be an intermediary who can choose which payer data to share with the provider.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenter sentiments about the various benefits to both providers and patients of providers having improved and direct access to patient data. As explained throughout this final rule, the requirements and standards for the Provider Access API will largely align with those currently in place and that we are finalizing for the Patient Access API. We anticipate that this alignment will provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API. Enabling improved data sharing directly with providers, who have the clinical expertise to effectively use the data to improve patient care, is a logical next step for our API implementation requirements.
                    </P>
                    <HD SOURCE="HD3">b. Compliance Dates</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the proposed 2026 compliance dates for the Provider Access API, as the appropriate time when the IGs will be sufficiently mature. Other commenters supported earlier compliance dates for the Provider Access API, including dates in calendar years 2024 and 2025.
                    </P>
                    <P>By contrast, multiple other commenters requested that CMS delay the implementation of the Provider Access API. Many recommended the compliance dates for the Provider Access API be at least 3 years after the issuance of the final rule to allow for provider and payer collaboration. Commenters stated this would allow payers and providers to stagger the separate implementation of the HIPAA Standards for Health Care Attachment proposed rule (87 FR 78438). A commenter stated that delaying the implementation of the Provider Access API requirement would enable the industry to develop consistent attribution methodologies and establish opt out policies. A commenter suggested that if CMS finalizes its proposal to require payers to implement Provider Access APIs and require a response within 1 business day, it should delay the compliance dates until 2027.</P>
                    <P>Multiple commenters flagged that CMS does not have to require implementation on any particular calendar date, since it would not affect an enrollee's plan benefits or premiums. A commenter specifically stated that the implementation does not need to be synchronized to the beginning of the plan benefit year for MA organizations and QHP issuers on the FFEs.</P>
                    <P>
                        A commenter sought clarification on the compliance dates as it relates to onboarding new providers to a payer's network, in order to ensure these new providers are following all applicable regulations, laws, and testing requirements by the proposed 
                        <PRTPAGE P="8790"/>
                        compliance dates in 2026. Multiple commenters recommended that CMS develop the Prior Authorization API before fully implementing the Provider Access API. A commenter further recommended that CMS phase in implementation of the Provider Access API. They believe CMS should allow additional time for development of the Provider Access API to maximize its utility and provided suggestions for additional capabilities to do this.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After consideration of public comments, we are finalizing a 1 year delay in the compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed in section I.D. of this final rule, we are delaying the compliance dates for each of our policies that require API development and enhancement (though other policies on new reporting metrics and prior authorization processes are being finalized with different compliance dates). While making data related to prior authorizations available to providers is necessary and urgent, we also understand that the policies we are finalizing will take time for payers to implement. An additional year will give payers time for a smooth rollout of this new API, as well as to onboard their providers. Payers may communicate these policies to any new providers through the same channels they currently use to communicate participation rules, coverage guidelines, and other important plan information with new providers joining their network. Because we are delaying the compliance dates, we do not believe a phased implementation is necessary, even if the additional time is used to implement functionalities for the API that we are not requiring in this final rule. We emphasize that the compliance dates are merely a deadline, and we encourage payers to meet the requirements of this rule as soon as possible to benefit their patients and providers. The additional year will also give impacted payers the requested time to establish the required attribution and opt out processes (discussed in sections II.B.3.a. and II.B.3.b. of this final rule, respectively).
                    </P>
                    <P>Finally, we decline to delay the compliance dates for this policy until after the Prior Authorization API is implemented and are finalizing the same compliance dates for all three new APIs. We agree that the purpose of the Prior Authorization API is to facilitate the exchange of structured (as defined in section II.A.2.a.ii. of this final rule) prior authorization data, and therefore receiving requests electronically may expedite payers' ability to make that information available to providers. However, even after the Prior Authorization API compliance dates, we expect that a number of prior authorizations are going to be submitted through other channels (hopefully in declining number). A provider's access to this information should not depend on the method and process that a payer sets for providers to submit a prior authorization request. Rather, the purpose of our Provider Access API policies is that providers have access to their patients' data (if patients do not opt out). That means that payers will need to be able to share through the required APIs any prior authorization information that is submitted in ways other than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027 compliance dates, we are providing payers an additional year beyond our proposal to implement the needed functionality within their internal systems. While we acknowledge that the compliance dates may not need to be at the start of a calendar, contract, or rating year, finalizing our proposal with specific compliance dates will ultimately reduce confusion for all parties.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter cautioned that without information that will be contained in an anticipated ONC proposed rule, it is difficult to provide realistic timelines for making prior authorization data available. They recommended that CMS offer an additional public comment period after the publication of this separate, anticipated ONC rule to allow the industry appropriate time to review the proposed changes that would be incorporated into the provider's workflow.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Regarding ONC regulations, we recognize that commenters are interested in future ONC policies which may relate to the policies in this rule. ONC issued both the HTI-1 proposed and final rules since the publication of our proposed rule. As discussed, cross references in this final rule have thus been updated accordingly. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. We further note that the Unified Agenda, at the time of publication of this final rule, has been updated to include an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955-AA06). The description indicates that the proposed rule aims to advance interoperability, including proposals to expand certified APIs for electronic prior authorization.
                        <SU>28</SU>
                        <FTREF/>
                         However, the policies in this rule can be finalized independently of future rulemaking by ONC and we are not providing an additional period for comment.
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             Office of Information and Regulatory Affairs. Executive Office of the President (2023). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Identifying Providers and Networks</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested clarification on the definition of “providers” that are eligible to use the Provider Access API. A commenter recommended that CMS permit providers who use a Type 2 National Provider Identifier (NPI) number to use the Provider Access API. Multiple commenters also believed that providers other than physicians should have access to patient data via the Provider Access API. A commenter recommended that the final rule explain whether the Provider Access API can be used by clinical laboratories. Another commenter believed that a Tax Identification Number (TIN) should be used for patient attribution purposes, rather than an NPI because it would give an opportunity for multiple providers in the same practice to access a patient's information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Providers who should have access to a patient's data are those, whether they are an individual, a facility, or a group of providers who have come together as an Accountable Care Organization (ACO), who are appropriately licensed, provide items or services eligible for coverage by the payer, and are enrolled with the payer or in the payer's provider network. Should a clinical laboratory, or other entity such as an ACO, meet these criteria, it would indeed be a provider who could use the Provider Access API to access patient data, assuming all other criteria outlined in this final rule are met. Multiple providers in the same practice may also be able to access a patient's data if the practice is enrolled with a plan under a Type 2 NPI (that is, an organization's NPI), or if those providers are part of an ACO that is 
                        <PRTPAGE P="8791"/>
                        requesting data on a provider's behalf, because all the providers in such organizations would be part of the payer's network. Furthermore, an ACO typically has business associate agreements with the providers that comprise the ACO, that should allow them to request data on the provider's behalf. Impacted payers may even elect to use patient rosters from such multi-provider practices or ACOs, as well as a practice's TIN, as part of its attribution process (see section II.B.3.a. of this final rule) since the patients on these rosters could be attributed to all the providers in these organizations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters sought clarification on how CMS defines a payer's network. A commenter inquired whether CMS's intention was to only include contracted providers who have both a contractual relationship with the payer and a treatment relationship with the patient, and as to which facilities are considered contracted or out-of-network. Another commenter asked for CMS to further define “treatment relationship with the patient.” A different commenter sought clarification on the definition of in-network providers for a plan that operates in multiple territories and has some providers that may be in-network for one location and out-of-network for another.
                    </P>
                    <P>A commenter further recommended that CMS consider how to allow for effective patient data transfers in more complex provider-facility relationships, meaning contracted individual and institutional providers. A commenter also recommended that CMS consider the nuances of cancer therapy networks when developing its final policies, as some payers utilize a cancer therapy network and cover services furnished by certain providers who may be considered out-of-network generally, but in-network for certain cancer treatments.</P>
                    <P>Other commenters suggested that CMS explain whether impacted payers with leased networks would be subject to the in-network requirement and recommended that leased network providers not be considered in-network for purposes of the Provider Access API. One of these commenters raised the concern that requiring QHP issuers on the FFEs to share patient information with leased network providers would impose a burden on QHPs, noting that the in- and out-of-network status of these providers could depend on a plan's benefit package. These commenters noted that these networks are often rented or leased from other payers, and that the QHP issuer that is renting the network may not have control over provider contract standards.</P>
                    <P>
                        <E T="03">Response:</E>
                         We are finalizing that impacted payers will be required to make the specified patient data available to in-network or enrolled providers with whom the patient has a verified treatment relationship (determined via an attribution process, as discussed in section II.B.3.a. of this final rule), assuming the data access conforms to all other applicable laws and regulations, such as state privacy laws. As discussed elsewhere, a payer can establish a treatment relationship by determining whether the patient's claims history, proof of an upcoming appointment, or other information (for example, hospital admission letter) demonstrates a treatment relationship with the provider. Nothing in this final rule would require the information used to verify the provider's relationship to the patient to be shared or exchanged via the Provider Access API itself. We also remind readers that, though we are not requiring payers to share patient data with out-of-network or unenrolled providers, we encourage them to do so to the extent permitted by law if they can verify a treatment relationship.
                    </P>
                    <P>Impacted payers that operate in multiple service areas, and therefore have some providers that are in-network in a particular area but out-of-network in other areas, should treat the providers based on network status on a case-by-case basis, depending on the payer's service area applicable to each enrollee. For example, if Providers A and B are both in-network for the plan, but Enrollee C resides in a service area where only Provider A is in-network, then the plan can treat Provider A as in-network and Provider B as out-of-network for making Enrollee C's data available via the Provider Access API. However, we remind readers that while not required, it would still be permissible to grant access to the Provider Access API to Provider B. The fact that Provider B already has a contract with the payer would even help to mitigate the potential privacy, security, and program integrity concerns we discussed in the proposed rule. The presence of this contractual relationship is also why we agree with the commenter regarding providers who are part of a cancer therapy network. If providers are in-network for some services for a patient, then they are an in-network provider. Our goal with our Provider Access API policies is to maximize the number of providers who can use it.</P>
                    <P>
                        We acknowledge that there may be health care settings and facilities where only some of the providers are enrolled with or have a provider agreement with the impacted payer (as applicable). Under the HIPAA Privacy Rule, covered health care providers generally may disclose certain PHI to other health care providers for treatment purposes.
                        <SU>29</SU>
                        <FTREF/>
                         Thus, there may be cases where a provider may share relevant patient data obtained via the Provider Access API with another provider who may not be in-network or enrolled with the impacted payer. However, under our requirements, payers would only be required to share data through the Provider Access API in response to requests from in-network or enrolled providers (as applicable).
                    </P>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.506(a).
                        </P>
                    </FTNT>
                    <P>
                        Providers in a leased network are in-network for purposes of the Provider Access API requirement because the lease effectively creates a contract with the providers in that network. By way of example, QHP issuers on the FFEs include leased network providers in the Network Adequacy template they submit as part of the annual QHP Certification application process, to the extent that a network's providers are available to enrollees in that QHP and are treated by the issuer as providing in-network benefits.
                        <SU>30</SU>
                        <FTREF/>
                         In addition, per 45 CFR 156.340, QHP issuers on the FFEs are responsible for their own compliance and the compliance of any delegated 
                        <SU>31</SU>
                        <FTREF/>
                         or downstream entities 
                        <SU>32</SU>
                        <FTREF/>
                         with all applicable Federal standards related to Exchanges.
                    </P>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             ECP and Network Adequacy (n.d.). Essential Community Providers and Network Adequacy. Retrieved from 
                            <E T="03">https://www.qhpcertification.cms.gov/s/ECP%20and%20Network%20Adequacy.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             A “delegated entity” is defined at 45 CFR 156.20 to mean any party that enters into an agreement with a QHP issuer on the FFEs to provide administrative services or health care services (for example, contracted providers).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             A “downstream entity” is defined at 45 CFR 156.20 as any party that enters into an agreement with a delegated entity or with another downstream entity to provide administrative services or health care services (for example, subcontracted providers).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Provider Adoption and Use</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters agreed with the scope of the Provider Access API, but expressed concern about potential penalties for providers who are unable to adopt technology that supports data exchange via this API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose any requirements for providers to use the Provider Access API, nor did we propose penalties for providers who do not use the API. However, accessing patient data through the Provider Access API will improve providers' ability to furnish quality care to patients. We expect that providers too 
                        <PRTPAGE P="8792"/>
                        will see the benefit of this technology and having patient data available directly from payers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters flagged that providers should have access to a patient's health information without technological or financial barriers, and that CMS should consider the costs to health centers, safety net providers, long-term and post-acute care (LTPAC) settings, and hospitals with low resources, as well as their unique needs with regard to implementing use of the Provider Access API. They believed that considering these provider types would ensure more widespread use of the API. A commenter stated that some small businesses do not have the staff or funding to set up a complex data exchange and they believed there is a need to engage them in discussions about the benefits of the health information exchange. Another commenter stated that the proposed rule did not offer any indication of available resources to help providers implement the API. A commenter recommended CMS consider investments that health centers make to ensure appropriate interoperability and access.
                    </P>
                    <P>A commenter urged CMS to track and counteract any equity issues that may manifest from operationalizing the Provider Access API. Multiple other commenters flagged that the true impact of APIs on everyday practices will not be understood until they are implemented and being used by providers, with another commenter recommending that CMS focus targeted efforts to engage provider specialties and groups who have traditionally lagged in uptake of interoperable technology.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that technology should not be a barrier to accessing appropriate patient information and our policies are intended to make such access easier for providers. We recognize that there are care settings that lag in adoption of EHR and other health IT, and/or lack the staff or resources to make use of the Provider Access API, which could result in these care settings missing out on the benefits of data exchange. Nevertheless, making data available via a FHIR API, which ensures these data are available to any authorized system seeking to access it, will benefit settings that may not have sophisticated technological solutions. Furthermore, making these data available is a vital antecedent to increased data sharing and interoperability across the health care system. We will be closely monitoring implementation and use of the Provider Access API to assess its real-world impact on care delivery, such as the possible equity concerns described by the commenters, as well as continue to work with providers to encourage and enable them to use the API, should they wish to do so.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS seek to understand the current state of health IT and the needs of end users before mandating Provider Access API implementation. A commenter stated that the health IT infrastructure across the industry is not ready to support the APIs. Another commenter representing payers, providers, and clearinghouses in both the public and private sector noted that when they surveyed their payer members on the Provider Access API implementation, 64.3 percent of payers responded it would be “very difficult or difficult” to implement.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree with the commenters' assessment that existing health IT infrastructure is not ready to support the Provider Access API. Payers are currently required to maintain a Patient Access API that enables the exchange of the same data as we are requiring to be available via the Provider Access API, with the caveat that this rule establishes new requirements to include information related to prior authorizations. The Patient Access API establishes the foundation to ensure that existing payer health IT infrastructure is indeed capable of also supporting the Provider Access API. For providers, as of October 2018, eligible professionals and hospitals collectively received over $38 billion in incentives to adopt, implement, upgrade (AIU), and demonstrate meaningful use of certified EHR technology (CEHRT) through the Medicare and Medicaid Promoting Interoperability Programs (formerly the Medicare and Medicaid EHR Incentive Programs).
                        <E T="51">33 34 35</E>
                        <FTREF/>
                         As of 2021, 78 percent of office-based physicians and 96 percent of non-Federal acute care hospitals had adopted CEHRT.
                        <SU>36</SU>
                        <FTREF/>
                         CEHRT now incorporates functionality for standards-based FHIR APIs. We thus believe health IT developers can build on these standards-based APIs to further develop functionality in provider systems that supports access to Provider Access APIs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             Centers for Medicare and Medicaid Services (2018). Promoting Interoperability (PI) Program Medicare Incentive Programs. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.</E>
                        </P>
                        <P>
                            <SU>34</SU>
                             Centers for Medicare and Medicaid Services (2018). Promoting Interoperability (PI) Program Medicare Incentive Programs. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.</E>
                        </P>
                        <P>
                            <SU>35</SU>
                             Centers for Medicare and Medicaid Services (2017). MA Organization (MAO) Incentive Payments for Eligible Professionals. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2017_MAO-Report.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2020). National Trends in Hospital and Physician Adoption of Electronic Health Records. Retrieved from 
                            <E T="03">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters underscored the need to establish incentives for providers to adopt the Provider Access API to offset any provider burden. Commenters cited quality measure reporting through the MIPS and CEHRT programs as possible avenues for incentives. Another commenter recommended that CMS and ONC work together to create incentives for vendors to improve EHR functionality and for providers to utilize the API, as well as provider educational resources to encourage adoption.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         For reasons explained previously, we believe that providers will see the benefit of using the Provider Access API, but we intend to closely monitor providers' experience, as well as consider ways to encourage use of the API in future rulemaking, if need be. We remind readers that nothing in this final rule would prohibit impacted payers themselves from incentivizing and/or requiring use of the Provider Access API. However, should they choose to implement such a policy, we remind impacted payers to carefully weigh the expected benefits against any potential new burden on providers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that the Provider Access API may be duplicative of existing resources (for example, HIEs or HINs, multi-payer portals, or other existing mechanisms for accessing claims data). Many other commenters supported creating the ability to integrate information from the Provider Access API into the provider's EHR system. These commenters recommended that CMS work closely with both providers and EHR vendors to ensure that integrating data from the Provider Access API is user-friendly and incorporated into the clinical workflow. They stated that that would make patient data from the Provider Access API organized and navigable. Another commenter stated that because patients often receive care from multiple health providers, they often have fragmented patient health records, which can make it difficult for providers to get a clear picture of a patient's health history.
                    </P>
                    <P>
                        Multiple commenters, however, expressed concerns regarding the feasibility of the Provider Access API. A 
                        <PRTPAGE P="8793"/>
                        commenter stated that the biggest challenge to the implementation of Provider Access API is that providers generally interact with many payers and it is not feasible for provider organizations to support many one-to-one connections with payers. The commenter stated that while it would be costly and risky, the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse has never been greater.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand commenters' concern about the potential for duplication of the Provider Access API functionalities that existing resources may provide. However, not all providers currently use or have access to other resources that can access patient data.
                        <E T="51">37 38</E>
                        <FTREF/>
                         Further, the data we are requiring payers to make available under this final rule may not be available from other sources. Thus, the Provider Access API can be a valuable tool for providers, even if they currently have access to data via an HIE/HIN or other source. We anticipate that providers will find benefits to patient care from having patient data available from multiple sources.
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2021). Electronic Health Information Exchange by Office-based Physicians. Retrieved from 
                            <E T="03">https://www.healthit.gov/data/quickstats/electronic-health-information-exchange-office-based-physicians.</E>
                        </P>
                        <P>
                            <SU>38</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2023). Interoperability and Methods of Exchange among Hospitals in 2021. Retrieved from 
                            <E T="03">https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021.</E>
                        </P>
                    </FTNT>
                    <P>We emphasize that the responsibility for implementing and maintaining the Provider Access API falls on impacted payers, not on providers or provider organizations. Further, in this final rule, we prioritize sharing structured data elements through standardized APIs (see section II.A.2.a.ii. of this final rule). Thus, even though this final rule does not obligate providers to use the Provider Access API, we anticipate that health IT vendors will integrate data from this API for providers in a manner that is organized, navigable, and useful to providers. We encourage vendors to work with their clients so that information accessed via the Provider Access API is useful for filling in gaps in the patient record, rather than creating duplicative data, and providers can take full advantage of their benefits.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that CMS should take steps to ensure that costs borne by EHR vendors are not passed onto providers, and that implementation is done in a manner that minimizes burden for providers. Multiple commenters also recommended that CMS explicitly require payers to allow providers to use the Provider Access API at no charge and that CMS should monitor and enforce such a requirement against payers who attempt to charge providers a user fee to access the APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Our goal is to improve care and reduce burden on patients, health care providers, and payers. We also recognize that EHR vendors, providers, and payers have costs of doing business. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers' API endpoints. Furthermore, EHR vendors and payers should ensure that any fees charged per API call are necessary and reasonable based on any actual maintenance costs for that entity. We also strongly encourage payers to permit providers to use their Provider Access API at no cost to maximize usage and benefits to patient care, which would ultimately benefit the payer as well. We will continue to work with interested parties to ensure that health care providers are not unnecessarily burdened and to ensure that our regulations do not place conflicting or unnecessary burdens on entities that may be regulated by more than one Federal agency.
                    </P>
                    <P>
                        Furthermore, EHR vendors and some impacted payers may be information blocking actors (as defined at 45 CFR 171.102) that must abide by ONC's regulatory requirements. Specific details of the information blocking regulations and other regulations issued by ONC are outside the scope of this final rule. Additional information about ONC information blocking regulations is available from the Information Blocking page of ONC's website: 
                        <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                         Questions may be sent to ONC's Health IT Feedback and Inquiry Portal at 
                        <E T="03">https://inquiry.healthit.gov/.</E>
                         Payers who are information blocking actors (as defined at 45 CFR 171.102) and have committed information blocking (as defined at 45 CFR 171.103) may be subject to civil money penalties by the HHS Office of the Inspector General (OIG). Interested parties should address questions regarding when particular practices might be considered information blocking to ONC.
                    </P>
                    <P>Finally, we did not propose to implement a prohibition against payers charging providers a user fee to access their APIs. We will closely monitor implementation of the Provider Access API and whether user fees present a significant impediment to interoperable data exchange. We will also be monitoring the frequency and type of feedback we receive from providers, patients, and payers related to burden and cost, to determine whether other policies might be ripe for consideration in future rulemaking. See section I.D.2. of this final rule for more information about CMS's enforcement and compliance policies.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter wanted to ensure that payers cannot require providers and clinical staff to use multiple different tools that might leverage the Provider Access API to treat patients. The commenter stated that providers should have autonomy to deliver care without having to add new technology that payers may require them to implement. Another commenter similarly recommended that CMS ensure payers do not increase burden on providers, stating that a significant burden would be placed on providers if their network participation gets conditioned on payer requirements to use the Provider Access API. Another commenter urged CMS to prohibit payers from placing additional contractual demands on providers, such as unrealistic turnaround times for physicians to retrieve patient information. The commenter expressed concerned that if providers cannot comply with payers' potential new requirements, they may be forced out of network.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         This rule does not require payers to impose requirements to use the Provider Access API on their in-network or enrolled providers. However, both providers and patients can benefit from the improved interoperability facilitated by FHIR APIs, with providers in particular seeing the benefits of having more patient data available to them. Contractual requirements set by payers for their in-network or enrolled providers are out of the scope of this rule. Nonetheless, if payers do choose to require providers to use the Provider Access API in some capacity, or even if they develop and require their own apps, we expect that they would do so to improve coordination with the provider and patient care, and also in a way that does not add provider burden.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that clinical data managed by payers are often derived from claims submitted by providers, which often results in them being in a different level of detail and format than clinical data exchanged between providers. The commenter stated that when the data are made available to providers, clear communication of those differences and accurate interpretation by the receiving provider's system is essential for enabling the provider to use the data to 
                        <PRTPAGE P="8794"/>
                        address care gaps and make treatment decisions. The commenter added that because the data are derived from claims, which would have been submitted by many of the same providers requesting it from the payer, deduplication of the data can become more complex. They further recommended that standards for representing the provenance of data when transmitted from payers to providers be enhanced to avoid adding a reconciliation burden on providers who receive the patient data. Another commenter said that EHR vendors would need to develop a “curation function” that could allow providers (and patients) to select the specific data to incorporate into the patient's record, warning that without this capability, there will be a significant amount of duplicate and junk data that will render the Provider Access API unusable.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenter for the comments, and we appreciate the concerns regarding the level of detail, format, and potential duplication of data received by providers' systems. One of the IGs we recommend for the Provider Access API is the PDex IG (see Table H3 in section II.G. of this final rule) is a set of guidelines that describes how to exchange data between payers and providers. A key PDex IG feature is the capability to include provenance records, if they exist, when exchanging data. Provenance records describe where the data came from and how they were processed. The PDex IG strongly recommends that payers create provenance records when they are not included in a data set. We also strongly recommend provenance records in cases, like those cited by the commenter, when clinical data are derived from claims. The provenance profile contains contextual information about the data, including the data's original author(s), transmitters, and formats (including whether they are derived from a claim-related transaction). Thus, using the PDex IG can help mitigate the problem of duplicating data by including provenance information. We also strongly recommend that the data source be included at the point of record creation, so that users can appropriately understand the source and context of the data. While we acknowledge the potential complexity of deduplicating data, creating contextual provenance information could help providers' systems identify data that already exist in the system, which can make the data actionable, rather than duplicative. In this way, payers can help providers unlock the benefits of accessing patient information through the Provider Access API. Finally, nothing in this final rule obligates providers to incorporate data they access via the Provider Access API into their patient's record, if they do not believe there is a benefit.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS permit payers to include audit rights and penalties in their provider contracts to ensure that payers are able to monitor and regulate information access requests, as the structure of the proposed rule effectively asked payers to trust that providers who request access to patient information have a valid need to access that information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Nothing in this final rule prohibits impacted payers from including additional requirements in their provider contracts and/or terms of service for requesting patient data. However, we emphasize that our requirement to provide access is limited to in-network providers who have a treatment relationship with the patient. We understand that payers need to ensure that provider requests are appropriate, so it follows that those entities would want to define roles and responsibilities through provider contracts, as these are established vehicles which delineate other payer requirements. If payers choose to implement such requirements, or a separate terms of service agreement, we strongly encourage them to balance the benefits to patients against any additional burden this would place on providers. Further, our requirements on the impacted payer will ensure that patients are informed of their data sharing options and will have the opportunity to opt out of data sharing under this policy if they do not wish for their providers to have access to their data. Any requirements that payers implement to use the Provider Access API must not conflict with the HIPAA Rules, or any other applicable law. See sections II.B.2.j. and II.B.3.b.ii. for discussions on the interaction of this final rule with the HIPAA Rules.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters cautioned that this rule puts a large burden on payers with little burden on providers and that given the number of resources needed to implement the API, provider uptake is critical. A commenter further stated that this rule requires payers to build a new API and share information with providers without asking providers to contribute or share information with payers, which they believe will lead to a breakdown in communication between providers and payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed previously, the technical requirements for the Provider Access API align almost identically with those already established for the Patient Access API (85 FR 25510) that impacted payers are currently required to maintain. We also emphasize that our recommended IGs will provide further clarity for payers on how to implement the APIs, thus reducing some of the implementation burden. As we discuss in section II.B.3., we are not being prescriptive as to how impacted payers implement their attribution and opt out processes, so that they can design processes that work best for them. We believe that all parties will see the benefit of improved data exchange facilitated by the Provider Access API. Because this final rule does not prohibit it, impacted payers may also decide to require providers to share certain data with them as part of their network/enrollment requirements. In fact, we understand that such requirements already exist in some situations. However, should payers implement such polices, we expect that they would do so only to the extent that it would benefit patient care and not add provider burden. We strongly encourage payers to carefully weigh any expected benefits against this potential burden. Finally, the Health IT Certification Program has already established requirements for FHIR APIs in EHR systems, which creates the capability for providers to make data available to payers via FHIR APIs. Using those APIs would allow payers to implement any requirements in a way that imposes minimal burden on providers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS explain whether only providers, not EHR vendors, can trigger a request for patient records.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are only requiring impacted payers to make patient data available to in-network or enrolled providers. Vendors are not permitted to request data for themselves, as they are not providers and thus cannot meet the criteria for making such a request. However, an EHR vendor may request the patient data via the provider's system at the behest of a provider who is eligible to request the data, with appropriate authentication and if consistent with other applicable law.
                    </P>
                    <HD SOURCE="HD3">e. Data Content</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS streamline the proposed required data to limit duplicative information and potentially overwhelming providers. A commenter recommended that CMS initially focus the Provider Access API on sharing claims data before introducing other 
                        <PRTPAGE P="8795"/>
                        types of data. Another commenter recommended that CMS consider the burden that this proposal may place on providers if they must maintain multiple versions of USCDI and whether it would even be feasible for their EHR to support this.
                    </P>
                    <P>Multiple commenters, however, suggested additional data that should be made available via the Provider Access API. Some commenters suggested that to facilitate a simpler prior authorization request process, CMS consider requiring payers to make patients' insurance coverage information readily available to providers through the Provider Access API. A commenter recommended that patient data collected by payer-owned providers and health service companies also be included in the Provider Access API.</P>
                    <P>
                        <E T="03">Response:</E>
                         We understand the concern over duplicative information, and it is not our intention to increase provider burden. Under this final rule, we are only requiring the exchange of data that are already structured, meaning they can be received by the provider's system in a standardized format with defined data attributes—this includes data classes and data elements in the USCDI and FHIR resources (see more discussion of how we define structured documentation in section II.A.2.a.ii. of this final rule). Most EHR systems use standardized clinical data in their systems today and, if certified under the ONC Health IT Certification Program, are also required to use the data classes and data elements in the content standard at 45 CFR 170.213 (USCDI). There are IT solutions available for providers' EHRs or practice management systems, such as Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR apps, that can make the data received via the Provider Access API actionable and avoid duplicative information. Further, for administrative ease and consistency, we are keeping the required types of data consistent (excluding provider remittances and patient cost-sharing information, as explained elsewhere in this final rule) with those required under the Patient Access API. We did not propose to include patients' insurance coverage information, to which providers should already have access through existing channels with payers or from patients themselves. However, a Health Insurance Information data class has been added to USCDI v3, and includes the data elements Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.
                        <SU>39</SU>
                        <FTREF/>
                         As payers adopt USCDI v3 (as required after January 1, 2026, under the regulations at 45 CFR 170.213), this information would be required to be available.
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (2023). Health Insurance Information. Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/uscdi-data-class/health-insurance-information#uscdi-v3.</E>
                        </P>
                    </FTNT>
                    <P>We remind impacted payers that if there is additional information beyond that which we are requiring that they do or can share with providers, they can use the Provider Access API as a mechanism for sharing that information, as permitted by applicable law. To the extent that impacted payers maintain patient data (per the CMS Interoperability and Patient Access final rule [85 FR 25536]) collected by payer-owned providers and health service companies, only the data elements specified in this final rule are included in the Provider Access API requirements.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS support the development of content and technical standards for prior authorization decisions that can be incorporated into IGs for testing before requiring inclusion of prior authorization information in the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Our recommended IGs (listed in Table H3) are currently in production and several versions of the IGs have been updated since publication of the proposed rule. Additionally, the recently published PDex IG STU 2.0.0 specification includes a prior authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. The process for IG development is open and we encourage industry engagement in their further development via opportunities such a HL7 FHIR Connectathons.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS require USCDI v3, since the proposed Provider Access API would not be implemented until 2026. The commenter stated that the USCDI v1 does not have digital data standards for social determinant of health (SDOH), sexual orientation and gender identity (SOGI), nor other data standards important for public health capabilities, and this could be a missed opportunity to drive national digital data standardization in this area. The commenter suggested this requirement would create a business case and drive adoption of standards and a move by industry to align.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         At the time the proposed rule was published, USCDI v1 was the only standard included at 45 CFR 170.213. The HTI-1 final rule, however, finalized that USCDI v1 expire on January 1, 2026, and also adopted USCDI v3 at 45 CFR 170.213 (89 FR 1210). Both versions will be available USCDI versions at 45 CFR 170.213 until January 1, 2026. Until this date, payers may meet the Provider Access API requirements by sharing all data classes and data elements in either USCDI v1 or v3. After January 1, 2026, payers must make available all data classes and data elements in USCDI v3. ONC accepts submissions from the public for new USCDI data classes and data elements through the USCDI ONC New Data Element and Class (ONDEC) Submission System 
                        <SU>40</SU>
                        <FTREF/>
                         and regularly publishes updated versions of the USCDI.
                        <SU>41</SU>
                        <FTREF/>
                         Any change in a content standard at 45 CFR 170.213 will go through notice-and-comment rulemaking. Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. We specifically encourage impacted payers to make all data classes and data elements available from more advanced versions of the USCDI prior to the expiration date. We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards.
                    </P>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (n.d.). USCDI ONDEC (ONC New Data Element and Class) Submission System. Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/ONDEC.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             Office of the National Coordinator for Health Information Technology (ONC) (n.d.). United States Core Data for Interoperability (USCDI). Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that while there is a FHIR resource for a scheduled appointment, it is not included in USCDI v1, which means a provider cannot send an appointment even when they have implemented the latest version of USCDI. The commenter stated that adding that element would require additional EHR vendor development.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         All data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) for dates of service after January 1, 2016, maintained by the payer are required to be made available to the provider who requests them (assuming all other applicable requirements specified in this final rule are met). Whether or not a scheduled appointment data element is included in USCDI has no bearing on how API developers use the Scheduling 
                        <PRTPAGE P="8796"/>
                        and Appointment FHIR Resources for other purposes.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters disagreed with the proposal to require payers to include clinical documentation and forms related to a prior authorization, with one noting that this information will be duplicative of the clinical information in a person's medical record. Another commenter stated that clinical documentation is often submitted to payers in the form of lengthy PDF documents, and sometimes by fax, making manually translating these data into FHIR challenging and infeasible to do within the proposed 1 business day timeframe. A commenter recommended that CMS explain whether payers have to convert clinical documentation submitted by providers by fax or in PDF or JPEG file formats into FHIR. A commenter recommended that CMS require the same discrete data element standards that the agency applied to the original Patient Access API to the Provider Access API, since distributing patient clinical attachments to all requesting clinicians raises concerns under the HIPAA minimum necessary standard. The commenter stated that an alternative is that providers could share clinical attachments as needed through clinician data sharing consultation and collaboration. However, a commenter recommended that CMS should include the administrative and clinical documentation requirements and require specific information for prior authorization data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing the comments, we agree that the burden of requiring payers to make unstructured documentation (as explained in section II.A.2.a.ii. of this final rule) available via the Provider Access API outweighs the benefits such documentation would provide. Thus, like for the Patient Access API, we are finalizing a requirement that the Provider Access API include only structured administrative and clinical documentation related to the prior authorization requests.
                    </P>
                    <P>As with the Patient Access API, documentation received in an unstructured format does not need to be parsed and converted to structured data for the purposes of inclusion in the Provider Access API. However, if a payer does parse the unstructured documentation to store the contained data in a structured format, that structured data would then be “maintained” by the payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538). For example, a payer may receive and maintain an unstructured PDF that contains lab results. If a payer maintains those lab results in a structured format, they would be required to share them under this final rule. If they are maintained in an unstructured format, they would not.</P>
                    <P>We recognize that unstructured administrative and clinical documentation could be important to help providers understand certain prior authorization requirements, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing would require payers to make available any documentation or materials that the provider sends to the payer to support a decision that are received in a structured format. Since we are finalizing that only structured documentation be made available, and structured documentation are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving providers access to information about their prior authorization processes.</P>
                    <P>It is important for payers to make available the specific clinical data at which they are looking to make a determination on the prior authorization request, even if that information may be elsewhere in the patient's record. As to the commenter concerned about clinical attachments and the HIPAA Privacy Rule's minimum necessary standard, we refer them and all readers to section II.B.3.b.ii. of this rule for more discussion about the HIPAA Rules.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification on whether the data sharing requirement applies to only claims and encounter data that are available at the time of the request, reasoning that if so, it could avoid any inappropriate pressure on providers to submit claims immediately after the provision of an item or service.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Per the CMS Interoperability and Patient Access final rule (85 FR 25536), payers are only required to share data that they maintain as part of their normal operations. Nothing in this final rule would change that existing policy that payers are not required to reach out to providers or other entities to gather data that they do not maintain, if it is not part of their normal operations, in order to share via the Provider Access API.
                    </P>
                    <HD SOURCE="HD3">f. Provider Remittances and Cost-Sharing Information</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters agreed with CMS's proposal to not require payers to make available provider remittances and patient cost-sharing information, as it would likely only have a limited beneficial impact on care. A commenter stated the cost-related data currently available via from the Patient Access API are not very clear, which could lead to different implementations and increased ambiguity when implementing the Provider Access API. A commenter warned that implementers are inconsistent, with some sending Explanation of Benefits (EOB) scrubbed of the item level detail, whereas others exclude EOBs altogether and only provide clinical data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Regardless of whether provider remittance information or cost-sharing information are truly confidential or proprietary information protected from disclosure under Federal law (which we do not address here), excluding such data from the Provider Access API is appropriate. Thus, if commenters believe that cost-sharing information would largely not be helpful information for providers to have access to, then we emphasize that sharing this information is not a requirement for the Provider Access API. We further agree with commenters that including this information in the Provider Access API will have limited benefit for treatment or care coordination. This rule does not prohibit payers from sending that information. Therefore, if a payer believes that implementing their Provider Access API in such a way that includes provider remittances and patient cost-sharing information would provide benefit or reduce burden, they are not prohibited from doing so under this rule, and may do so consistent with other applicable laws.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters urged CMS to reconsider excluding cost-sharing information from the Provider Access API because providers with access to this information can make more informed decisions regarding patient care by incorporating cost into treatment plans, and in turn, maintain a good provider-patient relationship. A commenter encouraged CMS to examine standards-based, patient-facing, and real-time benefit check capabilities that can be facilitated by patient cost-sharing information. A commenter also cautioned that excluding provider remittances and cost information conflicts with the cost-sharing information needed to enable Good Faith Estimates (GFE) under the No Surprises Act (NSA), which was enacted as part of the Consolidated Appropriations Act, 2021 (CAA).
                        <SU>42</SU>
                        <FTREF/>
                         They suggested that the rule be revised to 
                        <PRTPAGE P="8797"/>
                        allow necessary cost-sharing information required under the NSA. Another commenter highlighted that providers must be able to calculate sustainable total cost of care for patients attributed to them as part of value-based payment models.
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             Public Law 116-260 (December 27, 2020).
                        </P>
                    </FTNT>
                    <P>Multiple commenters proposed potential solutions to facilitate the sharing of cost-sharing information. A commenter suggested that CMS consider a bi-directional exchange mandate (as opposed to one-way provider access to payer data) to cover payment and operations, in addition to treatment. A commenter suggested that it does not make sense to restrict patient cost-sharing information since it is available in the X12 270/271 transaction standard. The commenter stated the Provider Access API can potentially replace the need for a separate 270/271 transaction and instead incorporate the information in 270/271 transactions. Another commenter expressed that modifications could be made to the CARIN IG for Blue Button to align with the proposed requirement to remove remittances and cost-sharing data from the FHIR transaction.</P>
                    <P>
                        <E T="03">Response:</E>
                         While we appreciate the various suggestions we received; we did not propose any related policies because the primary purpose of our Provider Access API policies is to improve the exchange of data for health care treatment. We acknowledge that some providers may find cost information helpful for gaining a clearer picture of a patient's financial situation. However, there is nothing prohibiting a provider from discussing the costs of various items or services and comparing the costs when furnished in-network and out-of-network to help a patient understand how to limit their out-of-pocket costs. Further, in-network or enrolled providers should be generally aware of the costs of various treatments, as their contracts would address payment amounts and conditions of payment for services furnished by that provider to a covered individual. We finally note that the GFE provision of the NSA relates to prospective costs, rather than cost information from past claims; that provision is beyond the scope of this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the CARIN IG for Blue Button will require updates to support CMS's proposal to remove remittances and cost-sharing data from the FHIR transaction for the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Further development is currently underway on the CARIN IG for Blue Button, which is one IG that we are recommending to support the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule). These developments will support exchanging information without provider remittances and patient cost-sharing information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter supported CMS's effort to establish the infrastructure needed to support payment reform and value-based care initiatives via the Provider Access API, stating that these initiatives are critical to reducing the costs of health care delivery while maximizing quality for Medicare enrollees. Multiple commenters stated, however, that the Provider Access API does not facilitate sharing the complete set of information needed by providers for participation in value-based care programs and recommended that CMS prioritize additional information, such as financial targets, spending, coordination of care payments, payer-generated attributed beneficiaries, and cost performance reporting. They believe these would allow a better exchange of value-based care payment models' summary-level data. A commenter recommended that ONC and CMS encourage industry to prioritize APIs to exchange information that would reduce administrative burden and lead to value-based care scalability.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose to include cost information for value-based care, as the primary goal of the Provider Access API is to give providers both immediate and direct access to patient data in order to improve patient care. However, we remind impacted payers that they can use the API to exchange additional data, should they so choose. We agree that FHIR APIs have the potential to support participation in value-based care programs, as these initiatives are critical to reducing the costs of health care delivery while maximizing quality for patients. We will continue to explore ways to leverage FHIR APIs to achieve CMS and broader HHS priorities. The requirements in this final rule are a critical foundation for this future work.
                    </P>
                    <HD SOURCE="HD3">g. Prior Authorization Data</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported including prior authorization information in the data made available through the Provider Access API, noting that it would help future providers understand the patient's current health status more quickly and better meet their care needs, increase transparency, and reduce burden on patients and providers. A commenter stated that adding prior authorization information to the Provider Access API will enhance functionality and incentivize use of the API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support and agree that giving providers access to the same prior authorization data as patients will have a positive impact on patient care.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended not including “the quantity of services used” due to delays in claims processing. A commenter recommended that CMS include just the approved number of units.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In response to commenter feedback to both the Provider and Patient Access API proposals, we are finalizing our proposal with the modification that “quantity of approved items or services used to date” will not be a required field. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion of our reasoning.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended including a standardized comment code(s) and comment description(s) for each status update sent to the provider to help with future data analysis of prior authorization improvements and tracking quality metrics.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we consider five basic statuses (pending, active, denied, expired, authorization not required) to cover the general scope of a prior authorization requests and decisions, we do not intend to prescribe or delineate the exact statuses that payers must use. The requirement for the Provider Access API (and the other APIs in this rule) to include the status of the prior authorization is intended to provide information to the provider, patient, or other payer that is using the API to access this information. Therefore, compliance with the requirement is not based on using specific terms, but on providing clear information. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion on prior authorization status definitions.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS crosswalk the required types of data for the Provider Access API with the other proposed APIs to avoid duplication, such as having to include supporting documentation through the Provider Access API, even if it is available via the Prior Authorization API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         If the commenter is recommending that the Provider Access API make available a mutually exclusive set of data from the Prior Authorization API to avoid confusion, then we note that Prior Authorization API will not have prior authorization data from other providers. We refer readers to section II.D. of this final rule for our full 
                        <PRTPAGE P="8798"/>
                        discussion of the Prior Authorization API requirements. We further intend to provide educational resources related to all the APIs in this final rule. We are not finalizing our proposal that related unstructured administrative and clinical documentation be included in the prior authorization data that impacted payers would have to make available to providers via the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended including the following additional data elements related to prior authorization: timestamps of any change in the status of the prior authorization; date/time received, reviewed, denied/approved; how the decision was made; software tools/artificial intelligence (AI) tools used; and persons involved in making the prior authorization decision. Another commenter stated that prior authorization metrics should be available via the Provider Access API to give providers an aggregated view of their attributed patients' prior authorizations. A commenter also recommended that CMS should require payers to make available through the Provider Access API contact information for the entity responsible for managing the payer's prior authorization program.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While these specific additional data and functionalities may provide value to some providers at this time, we do not believe that the value outweighs the additional effort impacted payers would need to expend to add these data and functionalities to the Provider Access API. The PDex IG STU 2.0.0, which has been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, states that payers using this IG shall make available pending and active prior authorization decisions and related clinical documentation and forms for items and services (not including prescription drugs), including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date. It also requires a creation date, issued date, and specific codes relevant to the approval status.
                        <SU>43</SU>
                        <FTREF/>
                         However, as discussed in section II.G., we are not yet ready to require this IG. We are thus prioritizing the data that are most important and useful at this time for clinical decision-making in proximity to a patient visit. To use one commenter's example, requiring payers to provide contact information for the entity responsible for managing the payer's prior authorization program would be duplicative, as providers who have a contractual relationship with the payer should already be aware of whom to contact regarding their prior authorization submissions. Providers can also use the Prior Authorization API to obtain this information. We remind impacted payers, however, that they may choose to include additional information if they believe it adds value to patients, providers, or themselves and their own processes. FHIR inherently provides flexibility to include additional information without reducing interoperability and the associated IGs are designed to both require and constrain specific elements identified as core to the IG's use case. We encourage the public to engage in the HL7 balloting process 
                        <SU>44</SU>
                        <FTREF/>
                         to provide feedback on data elements they believe would be most widely useful and applicable.
                    </P>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             Health Level Seven International (2020). Da Vinci payer data exchange STU 2.0.0. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/davinci-epdx/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             Health Level Seven International. HL7 Balloting (n.d.). Retrieved from 
                            <E T="03">https://confluence.hl7.org/display/HL7/HL7+Balloting.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that sharing prior authorization information through the Provider Access API be required, even if the patient opts out.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We certainly agree with the benefits of providers having access to prior authorization information via an API and note that providers will have access to the Prior Authorization API. Providers will thus have access to these data for prior authorization requests that they make, regardless of whether the patient has opted out of the Provider Access API. We refer readers to section II.D.2.c. of this final rule for our discussion on patient opt out and the Prior Authorization API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter urged CMS to require impacted payers to provide a statement through the Provider Access API when they are not requiring a prior authorization for an item or service. The commenter stated that this will ensure a level of transparency and paper trail between payer and provider.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         This information will be available through the Prior Authorization API, so does not need to be included in the Provider Access API. We refer readers to section II.D. of this final rule for our full discussion of the Prior Authorization API requirements and section II.A.2.a.ii. for that of prior authorization statuses.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter encouraged CMS to work with impacted payers to ensure the supporting data fields of laboratory test results, clinical data, and a specific reason for a denial are standardized to ensure information is consistent across sources. They urged CMS to work with payers, providers, and patients to determine the balance of data included in the requirements and provide the needed clarification and guidance to all parties.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As explained in section II.B.2.e. of this final rule and in more detail in section II.A.2.a.ii. of this final rule, we are finalizing a requirement for payers to share only data that are already structured, which include laboratory test results, clinical data, and a specific reason for a prior authorization denial. We also remind readers that payers are not obligated under this rule to parse or convert documentation received in an unstructured format for the purposes of inclusion in the Provider Access API. However, they may choose to do so. We will continue to work with interested parties to ensure that all parties benefit from the data sharing requirements we are finalizing and explore possible enhancements to our policies that require API development or enhancement in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">h. Data Availability</HD>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that prior authorization information should be available from the entire duration of the patient's history and not just for 1 year after the last status change because it would improve transparency in decision-making for providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Like with the Patient Access API, we believe that 1 year after the last status change is the appropriate amount of time to require payers to make historical prior authorization information available to providers. While historical information can certainly affect and be useful in improving patient care, we believe that historical claims and clinical data are more important to providers than information about prior authorizations that have expired or been denied more than a year in the past. Furthermore, our policy allows payers to make these prior authorization data available for longer than 1 year, if they believe it adds value to patients, providers, or themselves and their own processes. To inform ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than a year.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter supported the payer maintaining patient health data and making available any data to the provider with a date of service on or after January 1, 2016. A commenter recommended that CMS explain whether all data included in this rule will be subject first to corporate data retention standards, then retained from January 1, 2016, to present. Another 
                        <PRTPAGE P="8799"/>
                        commenter sought clarification as to whether CMS's intention is to include all data since 2016 and not only the last 5 years.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We remind impacted payers that the policy we are finalizing aligns with the similar one finalized in the CMS Interoperability and Patient Access final rule: 
                        <SU>45</SU>
                        <FTREF/>
                         the data available through the Provider Access API are data with a date of service on or after January 1, 2016 maintained by the payer. By “maintained,” we mean data that are maintained as part of normal operations, as is currently the policy for the Patient Access API under the CMS Interoperability and Patient Access final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.119(h)(1)(i) for MA organizations, 431.60(g)(1)(i) for Medicaid FFS, and 457.730(g)(1)(i) for CHIP FFS, cross reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) for Medicaid Managed Care, cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) for CHIP Managed Care, and 45 CFR 156.221(i)(1) for QHP issuers on the FFEs.
                        </P>
                    </FTNT>
                    <P>We did not propose a policy for impacted payers to make data available only from the previous 5 years in either the proposed rule or the CMS Interoperability and Patient Access final rule, nor did we receive comments specifically in favor of shortening the timeframe to 5 years. However, we also recognize that the data a payer maintains dating back to January 1, 2016, could be a substantial amount and, depending on the capabilities of the provider's EHR or practice management system, potentially more than some providers will need. We remind providers that this final rule does not obligate them to incorporate data they access via the Provider Access API into their patient's record. While we are finalizing our proposal to require impacted payers to make available via Provider Access API any of the applicable patient data with a date of service on or after January 1, 2016, that the payer maintains, we will closely monitor whether this timeframe is appropriate, to inform possible future rulemaking.</P>
                    <HD SOURCE="HD3">i. Response Timeframe for Requested Data</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed their support for the proposal to require payers to share the requested patient data no later than 1 business day after the payer receives the request. A commenter stated this will enable the provision of historical health care data and may affect current care recommendations. Multiple other commenters sought clarification on whether the proposed 1 business day turnaround time for a payer to respond to a provider's request for patient data included time for payers to complete an authentication of the provider's identity and the provider-patient treatment relationship.
                    </P>
                    <P>Multiple commenters recommended that CMS increase the amount of time payers have to respond to providers' data requests. Recommendations included suggestions to establish a two-day response time to balance timely access to information and reduce the operational burden and cost of the requirement. Commenters also noted that not all provider systems are FHIR-enabled and that could lead to longer data exchange times. A commenter stated that because of CMS's technical standards, specifications, and IG requirements, payers will likely need more time than one day to comply with CMS's proposed requirements. They believe that payers may need additional time to establish technical connections and contractual terms for a first-time request from a provider.</P>
                    <P>However, other commenters believed the time for payers to respond to the data request should be decreased from 1 day and that the response should come as soon as possible, to be real-time or near real-time. A commenter sought clarification from CMS as to why 1 business day is allowed for the payer to respond to a request, particularly if the initial request is being transmitted during a patient visit. The commenter continued that real-time responses should be expected from new technology. Another commenter stated having real-time data would help providers see a more complete view of a patient's complete care history. A commenter warned that, often, providers and patients review data during a visit and that delayed access to the data could undermine efforts to promote care coordination and provider-patient engagement. A commenter also recommended that CMS consider requiring that the requested data be provided within 1 calendar day to accommodate facilities that have 24/7 operations, like SNFs.</P>
                    <P>
                        <E T="03">Response:</E>
                         We foresee providers needing access to the specified data in order to review them in proximity to a patient visit. Thus, we do not believe that the turnaround time should be greater than 1 business day. We specify in the regulation that a payer must make the data available through the Provider Access API no later than 1 business day 
                        <E T="03">after</E>
                         receiving a request from the provider, if all the following conditions are met:
                    </P>
                    <P>• The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process;</P>
                    <P>• The patient does not opt out of the Provider Access API; and</P>
                    <P>• Disclosure of the data is not prohibited by law.</P>
                    <P>Authenticating the identity of the provider will include confirming that the requesting provider is in-network or enrolled with the payer and the attribution process will include confirming that a verified treatment relationship exists. The technical standards at 45 CFR 170.215 set requirements for identity proofing and authentication processes that must be met in order for a provider's EHR or practice management system to connect to the Provider Access API and access a patient's data (see section II.B.2.k. for more discussion on authorization and authentication). Those standards allow authentication to be completed within 1 business day, if not immediately, when the provider accesses their system via login. Impacted payers can also verify the patient-provider treatment relationship before the provider request. In fact, payers are permitted and highly encouraged to design their attribution processes to verify treatment relationships prospectively. We believe that the patient relationship can be verified for the vast majority of providers who will be requesting data via the Provider Access API either ahead of time or relatively quickly. However, we recognize that this may be difficult, if not impossible, for a new patient's first visit because there will be no claims history between that patient and the provider. Thus, there might be instances where the conditions previously mention may take longer to be met for some data requests. We strongly encourage impacted payers to ensure completion of these steps in a reasonable amount of time, so the provider can make use of the data they are requesting.</P>
                    <P>While we appreciate the commenters who pointed out that some providers might need the patient information as soon as possible or in real time, we also believe that requiring that standard would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able.</P>
                    <P>
                        We are therefore finalizing our proposal that impacted payers respond to a provider's request for patient data no later than 1 business day after the payer receives the request if all conditions are met. This timeframe adequately balances a provider's need for timely data with impacted payers' capability to make data available. Further, as discussed in detail in section II.A.2.a.ii. of this final rule, we are not 
                        <PRTPAGE P="8800"/>
                        finalizing our proposal for impacted payers to share unstructured documentation related to prior authorizations, as sharing such documentation would currently be difficult to accomplish in 1 business day.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the required response time for the Provider Access API could be administratively time consuming because the process to determine whether a disclosure is permitted under applicable law is a manual process that involves research, review, and analysis to determine which laws are applicable to the requester of the information, the type of data requested, and the intended recipient. Another commenter recommended that CMS consider the extent to which payers will be burdened by connecting and testing EHRs to facilitate the Provider Access API implementation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are only requiring impacted payers to share data elements that are already structured, and are requiring certain mature IGs and standards (see Table H3 in section II.G. of this final rule) that will enable the Provider Access API to connect to third-party apps and/or providers' EHRs or practice management systems. Because of this foundation, along with the 2027 compliance dates that we are finalizing, payers should have sufficient time to not only test their API connections, but also to develop internal processes and train staff to make the necessary determinations of which of the known and structured data are permitted to be shared via the Provider Access API. For instance, impacted payers may use this time to develop processes that flag certain data elements—as the payer receives them—as those that may require special permissions or are prohibited to disclose under other law. Such processes can ease any manual review and decision-making that might be necessary when a provider requests patient data.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS make it clear that the provider must request access to patient data and attest to their treatment relationship with the patient at the time of connection.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While payers might utilize a process for providers to attest to a treatment relationship at the time of the data request, we did not propose, nor are we finalizing such a requirement. This is not the only way to attribute patients, but impacted payers are certainly permitted to utilize a provider attestation as part of their attribution process (discussed in section II.B.3.a. of this final rule). Our regulations do not prohibit using an attestation where another law that permits disclosure requires an attestation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters sought clarification on whether CMS's 1 business day proposed requirement complies with the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act) around information sharing “without delay.”
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to section II.A.2.a.iii. of this final rule for a discussion of how our timeline requirements relate to ONC information blocking regulations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS require payers to notify providers once they have received a request and the specific date a provider should expect to receive information in response.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we did not propose such a requirement, it would be good practice for the payer to verify that they have received the request for patient data from the provider. We expect payers to have a process for providers to track their requests. Additionally, it would benefit providers for them to receive a notification if the patient cannot be attributed to them. In the DPC pilot, participating providers have the ability to request data for a patient with whom they have no prior treatment relationship, however they will receive a response with no data if they do so.
                    </P>
                    <HD SOURCE="HD3">j. Interaction With HIPAA Privacy, Security, and Administrative Transaction Rules</HD>
                    <P>
                        Under our policies, all data shared and received via the Provider Access API must be handled in a way that is consistent with all applicable laws and regulations. Payers and health care providers that are covered entities under the HIPAA Rules 
                        <SU>46</SU>
                        <FTREF/>
                         are subject to the HIPAA Privacy and Security Rules.
                        <SU>47</SU>
                        <FTREF/>
                         Adherence to both the HIPAA Privacy and Security Rules helps to ensure that the covered entity disclosing patient data through the Provider Access API has appropriate security protocols in place. These include, but are not limited to, administrative and technical safeguards, such as security management processes; 
                        <SU>48</SU>
                        <FTREF/>
                         access controls; 
                        <SU>49</SU>
                        <FTREF/>
                         and audit controls.
                        <SU>50</SU>
                        <FTREF/>
                         Regardless of whether a provider meets the definition of a covered entity under the HIPAA Rules at 45 CFR 160.103, there may be state laws that require certain privacy and security protections for an HIE. Additionally, other laws, such as the regulations that focus on confidentiality of substance use disorder patient records at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual's permission to disclose certain health information. We requested comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             Under the HIPAA Rules at 45 CFR 160.103, a “covered entity” includes a health care provider who transmits any health information in electronic form in connection with a transaction covered by the subchapter. 
                            <E T="03">See</E>
                             also definitions of health care provider and transaction at 
                            <E T="03">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             45 CFR parts 160 and 164, subparts A, C, and E. Department of Health and Human Services (2022). Security Rule Guidance Material. Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.308(a)(1).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.312(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             Under the HIPAA Rules at 45 CFR 160.103, a “covered entity” includes a health care provider who transmits any health information in electronic form in connection with a transaction covered by the subchapter. 
                            <E T="03">See</E>
                             also definitions of health care provider and transaction at 
                            <E T="03">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.</E>
                        </P>
                    </FTNT>
                    <P>Commenters provided many thoughts and recommendations related to the Provider Access API's intersection with existing privacy laws, including the HIPAA Privacy Rule. We thank the commenters for their perspectives and will use the feedback to inform future guidance, educational resources, and/or rulemaking. We remain committed to safeguarding patient information across the health care industry. Our policies provide an opportunity to engage patients in their data sharing and privacy rights while offering them the opportunity to more meaningfully engage with their care.</P>
                    <P>
                        Our policies will not alter any obligation for providers or payers to comply with applicable law, including obligations for HIPAA covered entities to follow the HIPAA Rules. Such other applicable law includes, but is not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The minimum required security framework of the Provider Access API is specified in the technical standards at 45 CFR 170.215 and will allow payers to verify the requesting provider's identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer gives the provider permission to access data. The authentication protocols are those that allow the payer to verify the identity of the requesting provider. In addition to using these required protocols, the payer will be required to share the specified data only if it can also attribute the patient to the provider 
                        <PRTPAGE P="8801"/>
                        using an attribution process, as discussed in section II.B.3.a. of this final rule. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.
                        <SU>51</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             Health Level Seven International (2022). FHIR Security. Retrieved from 
                            <E T="03">http://www.hl7.org/Fhir/security.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Under section 1173(a) of HIPAA, the Secretary is required to adopt standards for specific financial and administrative transactions and may adopt standards for other financial and administrative transactions. Although our policies will facilitate sharing claims data from payers to providers for the purpose of helping to improve patient care, the FHIR API data transmission will not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.
                        <SU>52</SU>
                        <FTREF/>
                         We also did not propose a mechanism to report health care encounters in connection with a reimbursement contract that is based on a mechanism other than charges or reimbursement rates for specific services.
                        <SU>53</SU>
                        <FTREF/>
                         The Secretary has not adopted a HIPAA transaction standard applicable to transmitting claims or encounter information for a purpose other than requesting or issuing payment, thus HIPAA administrative simplification standards do not apply to the Provider Access API.
                        <SU>54</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             
                            <E T="03">See</E>
                             45 CFR 162.1101(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             
                            <E T="03">See</E>
                             45 CFR 162.1101(b).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             
                            <E T="03">See</E>
                             45 CFR 162.923(a).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">k. Technical and Standards Considerations</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS detail the requirements for the Provider Access API, with many offering that the rule should describe the workflow, authorization, provider authentication, and attribution processes in more detail. They cautioned that without a standardized governance framework and legal terms, it will be unreasonable to expect payers and providers to establish connections and respond to requests within a set timeframe since they will need to negotiate bespoke agreements.
                    </P>
                    <P>Multiple commenters stated that CMS's proposed standards and recommended IGs are insufficient for the Provider Access API. One payer cautioned that this would result in payers struggling to comply with the requirements and limited improvements to information exchange. Another commenter warned that the lack of endpoint standardization between payer and provider systems will likely create technical difficulties. A commenter stated that without requiring an IG for the Provider Access API, the data will not be standardized and might not be able to be directly incorporated into a provider's EHR or practice management system. A commenter also noted that the IGs that CMS recommends do not include direction for how sensitive data such as behavioral health data will be shared and with what privacy guidelines. A commenter was additionally concerned that the recommended IGs are not enough to support the attribution process.</P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to section II.G. of this final rule for further discussion regarding the required technical standards for the Provider Access API and IG maturity. Further, the IGs we are recommending, listed in Table H3, are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like segmenting sensitive data or the attribution process. We recommend that industry look to existing trust community agreements for guidance on a standardized governance framework and legal terms. These agreements include, but are not limited to TEFCA or others used by state and regional HIEs.
                        <SU>55</SU>
                        <FTREF/>
                         We anticipate that affected entities will need to adopt new practices and methods to enable data sharing with new trading partners, including payers supporting new types of interoperability with providers. This final rule affords flexibility to define those approaches. We will continue to evaluate and consider specifications that are well-adapted to meet the legal and regulatory needs for possible future guidance or rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>55</SU>
                             Office of the National Coordinator for Health Information Technology (2023). Common Agreement for Nationwide Health Information Interoperability. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-11/Common_Agreement_v1.1_FINAL_508_1.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS exercise caution when selecting authentication mechanism requirements for the Provider Access API and stated that allowing simpler authentication mechanisms may make it easier to incorporate into workflows. Another commenter stated that it is unclear the extent to which payers would be expected to support trust and authentication processes for individual clinicians via the OpenID Connect Core standard, versus SMART integration that could rely on organization-level authentication. They noted that without specificity on workflows for exchange and authentication, authorization, and consent processes, payers and developers will need to support the numerous permutations that could be adopted by providers to address those needs, increasing complexity and burden. The commenter acknowledged the specifications developed by the HL7® Da Vinci Project and others have begun to address technical aspects of those needs, however, they are not yet mature and, because they are technical standards, do not address needed governance agreements.
                    </P>
                    <P>Another commenter stated that while the FHIR resources in the current Patient Access APIs are mostly reusable, the mechanism for providers to access information is entirely different. The commenter discussed system authentication and access protocols (OAuth and OpenID Connect Core) that are used to enable members to use portal credentials to pull data into a third-party app. The commenter mentions that while OAuth can and should be used for server-to-server connections to enable access to a wider set of data while maintaining security practices, current APIs do not have this capability. Therefore, they believe that this modification to enable a health care provider to access data on multiple patients is a significant change and will require rebuilding the FHIR APIs available for provider access.</P>
                    <P>
                        <E T="03">Response:</E>
                         Impacted payers are required to use authorization and authentication protocols to verify the requesting provider's identity. However, there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. We are finalizing a modification to our proposal to not require the OpenID Connect Core for the Provider Access API. However, we are requiring impacted payers to use the SMART App Launch IG, which includes the capability to perform authentication via OAuth. However, we recognize that other methods such as Backend Services Authorization (which is included in both the SMART App Launch IG Release 2.0.0 and the Bulk Data Access IG v1.0.0), Mutual Transport Layer Security (mTLS), Unified Data Access Profiles (UDAP), or other trust community specified means may be appropriate depending on the needs.
                        <PRTPAGE P="8802"/>
                    </P>
                    <P>
                        The PDex IG,
                        <SU>56</SU>
                        <FTREF/>
                         which we are recommending payers use to support the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule), includes using mTLS for the purposes of authentication. We are also supporting efforts to further refine the specifications for security (that is, authentication) at scale through UDAP via the FAST Security IG and will consider recommending this specification in the future. We recognize the importance of scalable technologies needed to support secure, protected, and authorized connectivity and communication across a wide range of interested parties throughout the industry. There are several approaches available, including the ones cited by commenters, and others implemented by various trust networks operating throughout the United States today.
                    </P>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             Health Level Seven International (2020). Da Vinci Payer Data Exchange. Retrieved from 
                            <E T="03">http://hl7.org/fhir/us/davinci-pdex/STU1/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported CMS's proposed requirement to leverage the Bulk Data Access IG for the Provider Access API, so that if a provider has a panel of patients associated with a single payer, the payer can share those data asynchronously in one transaction.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support of our policies. As discussed in section II.G. of this final rule, we are finalizing our proposal for impacted payers to use the Bulk Data Access IG at 45 CFR 170.215(d)(1) to support implementation of the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS limit the API to only individual data requests and that CMS not require the FHIR Bulk Data Access specification at this time, but instead consider it at a later date after it has been more thoroughly tested by HL7. Multiple commenters also stated that more work is needed on the Bulk Data Access IG before it is mandated, as it has not been adequately implemented; this makes it difficult to assess if it will be able to meet the proposed need and timelines.
                    </P>
                    <P>Multiple commenters also highlighted concerns with the technical functions of the Bulk Data Access IG and noted that large bulk downloads could pull time away from more urgent requests. The commenters recommended that payers be able to put reasonable limits on bulk data requests or that CMS should remove the bulk data transfer from the initial requirements. A commenter stated that CMS should only require impacted payers to respond to requests for certain patient's data quarterly. The commenter stated this would ensure that vendors do not set a default of daily retrievals of data that risk sharing more patient information than necessary.</P>
                    <P>Multiple commenters additionally flagged that payers, especially smaller health plans, could struggle to respond to bulk requests within the 1 business day response period and that they could be faced with significant costs to implement this requirement correctly. A commenter stated concern about bulk patient attribution and requested CMS clarification and/or limitations on bulk data sharing requirements.</P>
                    <P>
                        <E T="03">Response:</E>
                         Bulk data exchange can allow payers to prioritize more urgent requests and defer bulk data requests until a later time when sufficient system resources can be allocated to create bulk data export. However, we remind payers that they are still required to comply with the 1 business day timeframe discussed in section II.B.2.i. of this final rule. We emphasize that although we are requiring impacted payers to support FHIR Bulk Data Access at 45 CFR 170.215(d)(1) under this final rule, this requirement does not obligate them to use it for every data exchange if it is not feasible. However, we agree with commenters that impacted payers have leeway to place reasonable limits on bulk data requests. At the same time, we also believe that the benefits of access to these data outweigh any potential concern that vendors will set daily retrievals of data. This is because a provider would first need to request the data for individual patients, as well as the fact that the Provider Access API is better suited to enable discrete provider use when seeing a patient, rather than ongoing patient monitoring.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the PDex IG could support the opt out process by adding a flag to indicate an attributed member has opted out of provider data sharing.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's suggestion and urge impacted payers to explore ways to leverage FHIR IGs for the other processes that we are requiring in this rule.
                    </P>
                    <HD SOURCE="HD3">l. Interaction With ONC Policies</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters made recommendations regarding how CMS can work with ONC. They recommended that CMS work with ONC to implement additional requirements as part of the ONC Health IT Certification Program for developers to implement API interfaces into CEHRT in such a way that fits with provider workflow.
                    </P>
                    <P>Multiple commenters also recommended that CMS partner with ONC to create guidance regarding implementation of the Provider Access API and the technical capabilities of payers, EHR vendors, and providers. A commenter further suggested that CMS work with ONC to ensure that both payers and CEHRT vendors are aligned in the technical capabilities to implement Provider Access APIs in a way that does not hamper provider workflow and negate efforts to reduce prior authorization burdens.</P>
                    <P>Multiple commenters strongly encouraged CMS to work with ONC to consider how the Provider Access API could be expanded in future rulemaking to support bi-directional, real-time data exchange between payers and providers to support patient care and to automate prior authorization requests, rather than a one-way data exchange from payer to provider. A commenter stated that including such criteria could ensure compliance with the ONC Cures Act final rule information blocking policies.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' support for leveraging of the ONC Health IT Certification Program to ensure APIs are implemented in a standardized fashion. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule, as well as to align and mutually reinforce all of our respective policies.
                    </P>
                    <HD SOURCE="HD3">m. Interaction With Trusted Exchange Framework and Common Agreement</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that promoting payer to provider information exchange through the TEFCA may be a better path to achieve improved data exchange, including that of large-scale data sets, between payers and providers, rather than a requirement to implement FHIR APIs. A commenter recommended that CMS should collaborate with ONC and the Recognized Coordinating Entity (RCE) 
                        <SU>57</SU>
                        <FTREF/>
                         to determine an approach for payers to fulfill the payer to provider exchange requirement by joining the TEFCA network once responses are required for requests made as payment and operations exchange purposes, as described in the Qualified Health Information Network (QHIN)) Technical Framework (QTF).
                        <SU>58</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             The Sequoia Project (2023). What is the RCE? Retrieved from 
                            <E T="03">https://rce.sequoiaproject.org/rce/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             The Sequoia Project (2022). Trusted Exchange Framework and Common Agreement QHIN 
                            <PRTPAGE/>
                            Technical Framework (QTF). Retrieved from 
                            <E T="03">https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="8803"/>
                    <P>
                        <E T="03">Response:</E>
                         We will continue to work closely with our ONC colleagues on our policies as they relate to TEFCA, including how it can support the exchange of large-scale datasets. As we wrote in the proposed rule (87 FR 76328), we agree that connections between QHINs can support exchange of patient information between payers and providers and could eventually provide the similar functionality to the Provider Access API. As requirements for using FHIR are incorporated into the QTF in the future,
                        <SU>59</SU>
                        <FTREF/>
                         Participants and Subparticipants 
                        <SU>60</SU>
                        <FTREF/>
                         will be positioned to not only exchange the same data using the same standards that we are requiring in this final rule, but to do so under the TEFCA framework. Participants under TEFCA may include those, such as payers, who have entered into a contract to participate in a QHIN. As we expect payer participation in TEFCA to become more widespread in the future, we will continue to explore how we can align policies that require API development or enhancement for payers with TEFCA to ensure Participants and Subparticipants can utilize this network infrastructure to meet these API requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>59</SU>
                             The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange Version 2.0. Retrieved from 
                            <E T="03">https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             The Sequoia Project (2023). How Can I Participate in TEFCA? Retrieved from 
                            <E T="03">https://rce.sequoiaproject.org/participate/.</E>
                        </P>
                    </FTNT>
                    <P>We remind commenters that though we are finalizing our proposals for APIs to use and comply with certain standards and technical specifications, this would not preclude payers from also leveraging QHIN-to-QHIN exchange or HIEs/HINs to exchange patient data.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS establish a consistent set of technical standards between TEFCA and the proposed APIs that are required so that the industry does not have to implement different standards depending upon the exchange partner or mechanism for exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         ONC and CMS will continue to work closely together to identify ways that TEFCA can support the payer API requirements. We further agree that use of TEFCA could help to reduce burden associated with implementation variation that may arise in developing direct connections with exchange partners. ONC and the RCE are implementing the FHIR Roadmap for TEFCA Exchange to align and accelerate adoption of FHIR across the industry.
                        <SU>61</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange Version 2.0. Retrieved from 
                            <E T="03">https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">n. Federal Matching Funds for State Medicaid and CHIP FFS Expenditures on Implementation of the Provider Access API</HD>
                    <P>In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the Provider Access API (this was also addressed in the proposed rule at 87 FR 76264).</P>
                    <HD SOURCE="HD3">o. Medicaid Expansion CHIP</HD>
                    <P>In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76264).</P>
                    <HD SOURCE="HD3">3. Additional Requirements for the Provider Access API</HD>
                    <P>Additional requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow.</P>
                    <HD SOURCE="HD3">a. Attribution</HD>
                    <P>Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For purposes of our policies, we use the term “attribution” as shorthand for the determination that a treatment relationship exists between the patient and provider. For the Provider Access API, we proposed to require impacted payers to maintain an attribution process to associate patients with their in-network or enrolled (as applicable) providers to ensure that a payer only sends a patient's data to providers who have a treatment relationship with that patient.</P>
                    <P>We are aware that the process of attribution can relate to many payer functions, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. We thus encourage payers to use processes that they already have in place to attribute patients to their providers for these other purposes.</P>
                    <P>We expect that many payers will rely primarily on claims data to establish a treatment relationship between a patient and a provider. Other payers might use existing patient rosters for individual providers or organizations, such as ACOs. For new patients, we explained that payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. We know that many providers already verify coverage with a payer before a new patient's first appointment. A payer could establish a process that aligns with that query, using some evidence of a scheduled appointment. Once confirmed, the provider would be able to request the patient's data in preparation for the visit. Payers may have other existing processes that they prefer to use. We did not propose a prescriptive attribution process in order to provide payers the flexibility to use systems and processes they already have in place, where appropriate, or to develop new policies and procedures to ensure that access to a patient's data through the Provider Access API is limited to providers who have a treatment relationship with the patient.</P>
                    <P>
                        CMS has implemented an attribution process in the DPC pilot for Medicare beneficiaries (the Medicare FFS version of the Provider Access API), which can serve as an example for impacted payers. The pilot requires HIPAA covered entities or their business associates to agree to certain terms of service before data can be sent to them.
                        <SU>62</SU>
                        <FTREF/>
                         The current Medicare FFS terms of service require each organization to maintain a list of patients that represents the patient population currently being treated at their facilities.
                        <SU>63</SU>
                        <FTREF/>
                         CMS requires providers to attest that they have a treatment-related purpose to add a patient to their group. This is accomplished by submitting an attestation with every request to add a patient to their roster. This pilot will continue to test methods to accurately attribute patients to their providers. The information gained from this pilot may assist the industry to develop procedures to identify providers under this requirement.
                    </P>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             Centers for Medicare and Medicaid Services (n.d.). Terms of Service. Data at the Point of Care. Retrieved from 
                            <E T="03">https://dpc.cms.gov/terms-of-service.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             Centers for Medicare and Medicaid Services (n.d.). Attestation &amp; Attribution. 
                            <E T="03">Data</E>
                             at the Point of Care. Retrieved from 
                            <E T="03">https://dpc.cms.gov/docsV1.html#attestation--attribution.</E>
                        </P>
                    </FTNT>
                    <P>
                        In addition, HL7 has developed a HL7 Da Vinci Risk-Based Contracts Member Attribution (ATR) List IG. The ATR List IG does not specify how the payer and provider identify these patients, but defines the protocols, data structure, and value sets to be used for exchanging a Member Attribution List. The Member Attribution List typically contains: (1) plan/contract information which is the basis for the Member Attribution List, (2) patient information, (3) attributed individual provider information, (4) attributed organization information, and (5) member and subscriber coverage 
                        <PRTPAGE P="8804"/>
                        information. The DPC pilot program has been working with the Da Vinci Member Attribution List workgroup towards compatibility with that IG.
                        <SU>64</SU>
                        <FTREF/>
                         The ATR List IG is also informing updates to the PDex IG. We encourage payers to review the information from the workgroup. We further note that the HL7 Argonaut Project, a private sector initiative that advances using FHIR, has developed an IG specifying how to use the Scheduling and Appointment FHIR Resources to communicate this information.
                        <SU>65</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             Centers for Medicare and Medicaid Services (n.d.). Groups. Data at the Point of Care. Retrieved from 
                            <E T="03">https://dpc.cms.gov/docsV2.html#groups.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             Health Level Seven International (2022). Argonaut Scheduling IG (Release 1.0.0). Retrieved from 
                            <E T="03">https://fhir.org/guides/argonaut/scheduling/.</E>
                        </P>
                    </FTNT>
                    <P>We solicited comments on our proposal to require payers to maintain an attribution process to associate patients with their enrolled or in-network (as applicable) providers to ensure that a payer only sends a patient's data to providers who have a treatment relationship with that patient. We requested comments on other examples of how patients can be attributed to the enrolled or in-network providers from whom they are receiving care, especially for a new patient-provider treatment relationship. We also requested comments on whether and how payers could attribute the patient to the provider at the time a provider makes a request for patient data through the Patient Access API.</P>
                    <P>As discussed in more detail elsewhere, we are finalizing our proposal without changes.</P>
                    <HD SOURCE="HD3">i. General Comments on Attribution</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed their support for CMS's proposed requirement that impacted payers maintain a process to verify a provider-patient relationship. Multiple commenters also underscored the importance of developing a patient attribution system to ensure those data are shared appropriately. A commenter further stated that payers should only develop an attribution process for in-network providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support for this proposal. We emphasize that the requirement we are finalizing—that impacted payers be required to make the specified patient data available to providers—only applies to those that are in-network or enrolled with the payer. However, we encourage payers to consider making the Provider Access API available to out-of-network providers. This rule requires that impacted payers maintain an attribution process to associate patients with their providers. Thus, if payers choose to make the API available to out-of-network providers, they would still need to establish an attribution process to ensure that a treatment relationship exists before making patient data available.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS align patient attribution requirements and processes across payer types and leverage the CMS Innovation Center to identify where the process can be streamlined. A commenter also recommended that CMS permit payers to set reasonable requirements for providers to demonstrate that the provider is treating an individual, which could reduce the risk of providers making unauthorized inquiries in the system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We recognize that there are multiple ways for impacted payers to verify a treatment relationship. Payers may already have a process that they want to use, so requiring a different process that deviates from an established and effective workflow may add burden. We encourage payers to work together to establish industry-wide principles and standards for patient attribution. As previously stated, payers are permitted to set requirements for providers as part of their processes, such as requiring an attestation of a treatment relationship and/or a need for the data. We agree with the commenter that such requirements should be reasonable and not overly burden providers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that some specialties are referred patients at a higher rate and requested that CMS take into account the additional burdens of the attribution process for providers who may only see a patient once. Another commenter suggested that the final rule should ensure that any attribution process will not negatively impact those patients who have a high number of providers. A commenter further noted the significant technological challenges of attribution and expressed concern that patients that most need their data to follow them through clinicians, systems, and payers are those that are most likely to have data discontinuity due to clinicians receiving erroneous patient data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We emphasize that payers should consider all types of patients and providers when designing their attribution processes to prevent creating disparities. Making the specified data available via API may be particularly beneficial for patients experiencing data fragmentation. Establishing and maintaining an attribution process will benefit patients who may see multiple providers, so that all such a patient's providers (assuming they are in-network or enrolled) can have access to necessary information. We remind readers that we are not being prescriptive on when attribution needs to take place, as long as it occurs before patient data are made available through the Provider Access API. We encourage payers to perform the attribution prior to the first visit and/or in a reasonable amount of time to determine whether there are legal restrictions on the data that may be shared and so that providers can have the opportunity to review any relevant data in proximity to the patient encounter.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed concern regarding the attribution process for Medicaid patients, noting that developing a proactive process for providers who will see a patient would be challenging for Medicaid agencies. Another commenter stated that there should be special consideration for patients with mental health and substance use disorder issues. For example, proof of upcoming appointments can be an inadequate test of a patient-provider relationship due to high “no-show” or cancellation rates. A commenter also stated that verifying a provider-patient relationship will be difficult to accomplish in a single business day.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand the concerns of Medicaid agencies, including challenges in attributing new patients, and believe that proof of an upcoming appointment could sufficiently indicate the patient-provider relationship. However, impacted payers have latitude to determine when proof of an upcoming appointment can be used. For example, payers may implement a policy where providers can only successfully receive requested data if they have an upcoming appointment with the given patient within a specific number of days. Such a process can also mitigate potential “no show” or cancellation situations which one commenter cited. Many providers confirm appointments in the days prior to their appointment. A patient who confirms their appointment in proximity to the visit is less likely to cancel or not show. As stated previously, impacted payers must send the requested data no later than 1 business day after the payer receives a request and the following conditions are met: (1) the payer authenticates the identity of the provider and attributes the patient to that provider; (2) the patient has not opted out; and (3) disclosure of the requested information is not prohibited by law. Nothing in the rule requires payers to establish that these conditions are met in one business day; rather, data must be made available 
                        <PRTPAGE P="8805"/>
                        through the Provider Access API no later than one business day after these conditions are met. We encourage payers to verify these conditions are met in advance as often as possible. If this is difficult or not possible, such as in the case of new patient visits, we strongly encourage payers to complete the attribution process in a reasonable amount of time with minimal involvement from the provider, so as not to increase burden.
                    </P>
                    <HD SOURCE="HD3">ii. Providers' Role in Attribution</HD>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification from CMS regarding whether the provider or the payer must maintain records of the attribution. They also asked how to account for ACO or value-based care coverage models that permit patients to choose a provider. Another commenter agreed, pointing out that most attribution processes in these coverage models are currently geared toward identifying a singular accountable primary care physician within value-based arrangements and that often, a patient's identification of “their doctor” may not match results generated through automated attribution approaches.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         This final rule imposes on impacted payers the requirement to maintain a process to attribute a patient to in-network or enrolled providers. Payers are responsible for maintaining attribution records and ensuring that only in-network or enrolled providers who have a treatment relationship with the patient (or should they choose, out-of-network or unenrolled providers to whom the impacted payer has attributed a patient) have access to patient data. However, the process of attribution inherently requires provider participation in some instances. For example, when a patient has their first visit with a particular provider, we cannot expect the payer to have that information without some provider input. In other instances, payers may involve patients in their attribution processes, especially if they wish to account for providers who might not be identified via existing automated approaches. Should they do so, any such involvement should not be onerous for the patient.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that CMS should allow payers and providers to adopt an approach that assures payers that any provider request for patient data meets the requirements of this rule, while also allowing providers to delegate the ability to request information to support staff. Another commenter sought clarification on whether physicians and their staff would be expected to operate outside of their normal workflows to demonstrate a care relationship with a patient. A commenter sought clarification on whether multiple providers could be attributed to the same patient at a time. A commenter further sought clarification on whether the rendering provider is the provider who has a treatment relationship with the patient, or if the billing provider could also be attributed to the patient to request data using the Provider Access API. A commenter stated that CMS should require payers to make an attribution prior to the first visit.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we are not being prescriptive in how payers should design their attribution processes; we caution that payers should not set overly onerous criteria for providers to prove their treatment relationship with a patient. Both patients and providers will benefit from the provider having access to the specified information; the attribution process should not impede this benefit. Furthermore, it is appropriate for providers to be able to delegate administrative tasks to their staff. Similar to other processes, such as submitting claims, payers should set reasonable requirements that allow staff to provide information or perform tasks on a provider's behalf.
                    </P>
                    <P>We do not intend to overburden providers or their staff with the attribution process. As stated, we believe that payers can attribute most patients to providers via claims, which should not require providers to operate significantly outside their normal workflows to demonstrate a care relationship with a patient. Furthermore, we acknowledge that patients can (and in many cases should) be attributed to multiple providers who would be able to request access to the patient's data. This may apply, for example, to a multi-provider practice or an ACO.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS reevaluate the attribution process as outlined in the proposed rule. Multiple commenters also stated that payers have significantly different attribution processes, and this adds burden to hospitals and SNFs. A commenter agreed that varying attribution processes across payers would increase administrative burden for providers and clinics under the proposed rule. A commenter recommended that CMS permit providers not only to attribute patients through individual requests, but also to be able to submit information in a bulk format by submitting a list of all a payers' enrollees currently in their care. Another commenter cautioned CMS to not adopt any standard for attribution more rigorous than the HIPAA Privacy Rule and avoid imposing burdensome requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We emphasize that the requirement to implement an attribution process applies to impacted payers, not providers. As discussed, a payer may verify the patient treatment relationship in a variety of ways. While verification may necessitate some action by the providers, we strongly encourage payers to implement a process that is least burdensome to providers as possible. When information from providers is required, payers should allow bulk submission in order to impose the least possible burden on providers. Finally, because we did not propose to adopt any attribution standard or method at all, we are not adopting one that is more rigorous than what is required under the HIPAA Privacy Rule.
                    </P>
                    <HD SOURCE="HD3">iii. Attribution Process Design and Suggestions</HD>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS establish minimum attribution criteria and a uniform claims attribution process. Multiple commenters suggested that CMS create guidance on best practices and specific ways that payers can accurately attribute patients to specific providers and when a payer can determine that a treatment relationship between a patient and provider has ended to allow flexibility in the attribution process rather. Multiple commenters also stated that payers should be able to “un-attribute” a patient from a provider when a treatment relationship is inactive to protect patient data. A commenter stated that it is crucial for CMS to define the timeline for which the patient attribution roster on both the payer and provider side must be updated to ensure that it is never shorter than the 30 days mandated by some states. A commenter also stated that the attribution process will be difficult because it will require two separate processes, one for new and one for established patients. A commenter further stated that payers will need to prioritize implementation of the Provider Access API, which will make developing an attribution process difficult.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In order to permit impacted payers the flexibility to leverage their existing processes or utilize another method that may be the least burdensome for them, we did not propose, and are not finalizing, a standardized attribution method. In the DPC pilot, for a provider to establish a treatment-related purpose for viewing patient data, they must have an existing “treatment relationship,” defined as a 
                        <PRTPAGE P="8806"/>
                        processed claim with the provider's NPI number for that patient within the past 18 months. The DPC pilot currently does not have the ability for providers to access data for patients before their first claim. As noted in the proposed rule and previously mentioned, with each roster addition or renewal, a provider must also attest that there is an active treatment relationship. We have had significant interest in our DPC pilot from providers and provider organizations that participate in the Medicare program and continue to gather information from interested parties. However, we do not have information beyond what is currently publicly available to share at this time.
                    </P>
                    <P>This DPC process is just one attribution method and we encourage payers to leverage their existing processes and develop methods that work best for them and that place the least amount of burden on providers. Nothing in this final rule would require a specific timeframe after which a treatment relationship expires. Payers are permitted to establish a period after which the treatment relationship is considered inactive and a patient could be un-attributed from a provider. However, many patients may only see a particular provider annually, which would clearly signify a continuing treatment relationship. We did not propose a requirement for providers to maintain a patient roster, though it may be required under other Federal or state regulations or under the provider's contract with the payer.</P>
                    <P>Finally, we understand that some payers may have challenges implementing an attribution process. One of the reasons we are finalizing a 2027 compliance dates rather than the proposed 2026 dates (see section I.D. of this final rule) is to give impacted payers additional time to prepare and test any new or modified process. We intend to provide more information and education on potential authentication processes prior to the compliance dates.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern with how difficult it is to verify the patient-provider relationship. A commenter sought clarification on the intended level of attribution for access to a member's data. Another commenter stated their belief that the proposed attribution requirement, specifically how a “treatment relationship” is defined, requires further development and feedback from consumers before implementation so that they can feel in control of their data. They noted that it is not uncommon to have dozens of providers involved in a single patient's care, nor is it uncommon to have a single interaction with a specialty provider, or to have a provider consult another provider on a course of care without the patient's knowledge.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Payers should be able to meet the requirement to have an attribution process by verifying the patient-provider treatment relationship in a variety of ways, as discussed in this section. Payers should consider Federal and state law, internal risk policies, and their own processes to determine what level of assurance they require to attribute a patient to a provider for the Provider Access API. Establishing specific requirements or procedures would add burden to payers who may establish different, but equally acceptable and effective, processes.
                    </P>
                    <P>We do not believe it is necessary to define a “treatment relationship” only for the purposes of this rule. Payers may have different definitions that may be based on Federal or state law, internal policies, or provider contracts. Therefore, an additional definition would be unnecessary, duplicative, and possibly confusing. We do note that if there is doubt about whether a patient and provider are in a treatment relationship, information from the patient could be one method of making that determination. However, we emphasize that placing burden on a patient should only be used a last resort, and only if the benefits of making data available outweigh that burden.</P>
                    <P>In some cases, verifying a treatment relationship could result in providers having access to data about patients they have treated only once and whom they may not treat again. However, we believe that these providers would have little reason to request this information because they would be creating unnecessary work for themselves without benefitting patient care. Further, data from the Provider Access API is only required to be made available to in-network or enrolled providers. Such providers have already been vetted to participate in the impacted payer's network, so it is unlikely these participating providers would seek out patient data they do not need for patient care. Finally, some impacted payers might utilize an attestation process, as suggested by some commenters, where providers must attest that they have a clinical need for any data they request. A provider requesting data that they do not need could endanger their payer network or contract status if they fraudulently attest that they are only requesting data for patient care, should the impacted payer implement such a policy. We thus believe that the benefits of the Provider Access API outweigh concerns that already-attributed providers will inappropriately request patient data. We look forward to working with interested parties to develop best practices for attribution processes.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that a claims-based approach to verifying a treatment relationship is the most reliable. Conversely, another commenter stated that it was not necessary to verify a treatment relationship through claims data. They recommended using processes that show the onset or evidence of treatment like Admission, Discharge, Transfer (ADT) or Scheduling Information Unsolicited (SIU) transaction. Another commenter stated that a hospital admission letter should be enough for payers to grant the provider access to the Provider Access API for the specified patient. A commenter also encouraged payers to consider whether a provider's signed order for treatment (on behalf of a patient) is enough to establish this relationship. A commenter highlighted that the CMS companion guide on the HIPAA-mandated eligibility transaction supporting Medicare Beneficiary Matching could serve as a model for data elements that could facilitate attribution.
                        <SU>66</SU>
                        <FTREF/>
                         These data and the associated eligibility and benefit request essentially serve as proof of a scheduled appointment. A commenter also recommended leveraging TEFCA for the attribution process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             Centers for Medicare and Medicaid Services (n.d.). HIPAA Eligibility Transaction System (HETS). Retrieved from 
                            <E T="03">https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response:</E>
                         Because different approaches and standards for an attribution process continue to evolve, we did not propose to specify how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encouraged the community to continue to collaborate on viable approaches. We agree that a claims-based approach is both reliable and puts little, if any, burden on providers. We expect that payers will also find this to be the simplest way to verify the treatment relationship because they will have a record of a treatment relationship as of the most recent date of service on a claim. We also agree that the other methods suggested could be leveraged by payers to attribute patients to providers for the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters highlighted existing resources or models that CMS could leverage to establish an attribution process. Another commenter recommended that payers be allowed to 
                        <PRTPAGE P="8807"/>
                        use the existing processes to verify treatment relationships, including the ATR List IG. Multiple commenters also stated that this IG could be updated to provide the necessary tools to support implementation of the attribution process and some recommended that CMS adopt that standard when it is mature enough for large scale implementation.
                    </P>
                    <P>Multiple commenters expressed support for HIEs and HINs as unique entities that have the capability to create and manage patient-provider attribution for the Provider Access API. The commenters provided an example from the Active Care Relationship Service (ACRS), which enables organizations to send data files that record the relationships between their providers and patients. Another commenter stated that CMS should work with HIEs to expand capabilities and create IGs and processes for patient matching, attribution, and opt out to support the Provider Access API.</P>
                    <P>
                        <E T="03">Response:</E>
                         We thank readers for their comments and will consider them for future guidance or rulemaking. As we did not propose a specific attribution method, we encourage impacted payers to consider these existing resources and models. As members of the HL7® Da Vinci Project, we will continue to monitor development of the ATR List IG.
                    </P>
                    <P>Impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private HIEs. These HIEs may already have a process to attribute patients to providers. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate the Provider Access API. Nothing in our policies prohibits a payer from using an intermediary to aid with patient matching, data exchange, or data hygiene. Once again, our goal is to allow payers to develop the least burdensome approach to attribution, and we encourage collaboration on potential solutions.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested that CMS consider implementing a national, digital patient identification standard. A commenter recommended that CMS implement a standardized patient identification framework to ensure that patient data are not inadvertently co-mingled and does not pose a threat to patient privacy and safety within the Provider Access API. Another commenter stated that an electronic standard should be developed to verify a patient relationship and appointment status.
                    </P>
                    <P>Multiple commenters stated the importance of making sure the CEHRT programs require that record requests can only be made when a treatment relationship is present. A commenter recommended that CMS and ONC work together to establish standards for ONC's Health IT Certification Program.</P>
                    <P>
                        <E T="03">Response:</E>
                         A standard unique health identifier for each individual, which is in accord with numerous commenters' recommendations, would be associated with a HIPAA standard arising at section 1173(b)(1) of the Act. We will continue to work with our Federal partners as we consider future guidance or additional rulemaking within the ambit of our authority.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS establish a workgroup or advisory committee to establish an appropriate attribution process. Another commenter recommended that CMS monitor the state of evolving technology and maintain flexibility in its requirements as technology continues to develop.
                    </P>
                    <P>A commenter recommended CMS utilize public feedback to establish minimum criteria as proof of an authentic patient-provider relationship, because a lack of clear guidance in this area may cause disputes between payers and providers regarding the appropriate criteria for establishing proof of a relationship.</P>
                    <P>
                        <E T="03">Response:</E>
                         We intend to continue our work with industry as they develop attribution processes that do not overly burden payers, providers, or patients. Additionally, based on feedback from the public, we believe that the public would benefit from further educational resources, and we will explore avenues by which we may offer those in the future.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter asked whether payers can integrate an attestation of a treatment relationship with a FHIR transaction.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we are not prohibiting use of a FHIR transaction as part of the attribution process, the IGs we are recommending are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like the attribution process.
                    </P>
                    <HD SOURCE="HD3">b. Opt Out</HD>
                    <P>We proposed that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of (or if they have already opted out, to opt back in to) having the patients' data available for providers via the Provider Access API. We noted that this differed from our Payer-to-Payer API, which was structured as an opt in process. Similar to the attribution process, as previously discussed, we did not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to give all patients or their personal representatives the opportunity to opt out, including those currently enrolled on the compliance dates, before making patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer.</P>
                    <P>We did not propose to require specific methods for patients to opt out, but anticipated that payers would make that process available by mobile app or on their website. We also anticipated that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate. We invited comments on whether we should establish more explicit requirements regarding the patient opt out processes.</P>
                    <P>Our proposal would require impacted payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer's network. However, we also encouraged payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of making data available to individual providers or groups of providers. We did not propose to require those more granular controls, as we were concerned about the potential administrative and technical burden this would place on some payers. However, we requested comments about the technical feasibility of implementing an opt out process that would allow patients to make provider-specific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking.</P>
                    <P>
                        We appreciate commenters' feedback to our requests, and understand concerns about the potential for administrative burden associated with providing patients with more granular controls over data sharing, as well as which specific providers can receive their data. We used the term “granular” broadly because we wanted to know which data elements commenters thought were most important to be able to segment out. We are committed to minimizing the burden on patients and providers as much as possible and continue to weigh the benefits of providing patients with more control over their data against the potential administrative burden on impacted payers. We appreciate the suggestions we received for how to implement a more granular opt out approach and will 
                        <PRTPAGE P="8808"/>
                        consider these suggestions for future rulemaking.
                    </P>
                    <P>We proposed an opt out approach because, as we discussed in the proposed rule, opt in models of data sharing have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and health care providers. We acknowledged that there are positives and negatives to both opt in and opt out policies, and that some patients may prefer to control or direct their health information via an opt in process, which requires affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring action by the patient. We stated our belief that opt out would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related to both opt in and opt out policies, especially as they relate to making data available to providers. We wrote that a policy defaulting to sharing data with providers, unless a patient opts out, appropriately balances the benefits of data sharing with the right of patients to control their health information. As we also detailed in the proposed rule, payers would be responsible for providing patient resources to ensure that patients understand the implications of opting out. We noted that, should patients not opt out of data sharing, then the data that would be made available via the Provider Access API would be available to in-network providers whose identity has been authenticated and to whom the patients have been attributed, meaning that the payer has verified a treatment relationship between the provider and the patient. However, we stated that our proposals, taken together, gave patients ample opportunities to change their data sharing permission as they see fit.</P>
                    <P>As we explained in detail in our proposed rule (87 FR 76260), opt in models can create greater administrative burden for smaller health care organizations, depending on where the responsibility for obtaining and updating the patient's data sharing permission is held. We also pointed to the fact that a larger health care organization that employed an opt in model, the Veterans Health Administration within the VA, saw the vast majority of provider requests for patient information rejected for lack of patient permission.</P>
                    <P>
                        We additionally stated our belief that an opt out model could address equity issues by ensuring that patients from lower socioeconomic and minority groups, who are more likely to have limited health literacy, can benefit from the improved care that the Provider Access API can facilitate. We believe that data sharing as the default option for all patients enhances both personal and organizational health literacy, as these terms are defined by the Healthy People 2030 report,
                        <SU>67</SU>
                        <FTREF/>
                         while protecting patients' choice to limit data sharing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             Health Literacy in Healthy People 2030 (2020). History of Health Literacy Definitions. Retrieved from 
                            <E T="03">https://health.gov/healthypeople/priority-areas/health-literacy-healthy-people-2030/history-health-literacy-definitions.</E>
                        </P>
                    </FTNT>
                    <P>The ability for patients to opt out was specific to the data we proposed requiring payers to share via the Provider Access API. As discussed previously, nothing in the proposed rule would alter any other requirements under applicable privacy and security laws and regulations. If there is other authority to share patient information with respect to which a patient may not opt out, such as disclosures required by law, nothing in this proposal would change the payer's obligation to disclose that information. However, we encouraged payers and providers to use the proposed Provider Access API as a technical solution to transmit data between payers and providers beyond the scope of these policies, provided such disclosure is consistent with all other applicable requirements, such as the requirements set out in the HIPAA Privacy Rule and the HIPAA Security Rule.</P>
                    <P>We value the importance of safeguarding the quality and integrity of patient health information. We acknowledged that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out models. We expect that if payers identify any vulnerabilities, they will work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information.</P>
                    <P>We requested comments on our proposal for a patient opt out framework for the Provider Access API. As discussed in more detail elsewhere, we are finalizing this proposal without changes.</P>
                    <HD SOURCE="HD3">i. General Comments on Opt Out</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for the proposed policy to require an opt out framework for the Provider Access API. Commenters provided various rationales for their support, including that the opt out framework would enable patients to protect and control their health information while still making patient data available to providers, encourage increased data transmission, and allow patients to terminate a provider's access to their data when the patient no longer has a treatment relationship with the provider.
                    </P>
                    <P>Multiple commenters specifically expressed their support for an opt out approach instead of an opt in approach. These commenters noted that it is less burdensome for payers and that an opt in approach would require patients to have a higher level of education or better technology and health literacy to utilize than an opt out process, which may result in fewer patients having their data exchanged via the Provider Access API under an opt in approach.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the comments we received in support of our proposal to allow patients or their personal representatives to opt out of the Provider Access API if they do not wish for their data to be made available via the API requirement. We agree with the commenters that an opt out approach will enable patients or their personal representatives to better protect and control their health information while still making patient data available to providers. We remind commenters that the opt out would not necessarily allow patients or their personal representatives to terminate a provider's access to their data when the patient no longer has a treatment relationship with the provider, because we did not propose to require a granular opt out policy (though some payers might choose to implement such a policy). However, we did note in section II.B.3.a. of this final rule that payers have latitude to determine when a patient-provider treatment relationship ends via their attribution process. Thus, regardless of the opt out granularity, payers should also use their attribution process to determine whether and when an individual provider should have access to a patient's data via the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Other commenters voiced their concerns with an opt out approach but did not specifically recommend that CMS take a different approach. Multiple commenters noted that offering patients an opportunity to opt out would limit information sharing and that 
                        <PRTPAGE P="8809"/>
                        information sharing is important to facilitate the prior authorization process. Multiple commenters also stated their belief that an opt out approach would reduce, or even remove patient control over their health information. Those commenters stated that because CMS expects most patients not to opt out, the confidentiality of this patient data will effectively not be the default.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         For reasons we discussed in both the proposed rule and previously, the opt out approach appropriately balances the benefits of data sharing with the ability of patients to control their health information. All patients will be given the opportunity to opt out of our Provider Access API policy. We agree that this information sharing is important to improve the efficiency of the prior authorization process and to ensure that patients have timely access to the care they need. While patients may opt out of data flowing from their payer to their provider via the Provider Access API, they cannot opt out of the prior authorization process established by their payer or the communications between their provider and payer that enable that process.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS adopt an opt in approach instead of an opt out approach for the Provider Access API. Commenters provided various rationales for recommending an opt in approach, including that an opt in would give patients more control over their data and is more understandable than an opt out process. A commenter explained that while they support an opt in approach, they do not agree that it would benefit disadvantaged people (such as people with low health literacy or limited English proficiency) because patients may not understand what it means to give permission for data sharing. Multiple commenters also supported an opt in approach due to patient privacy concerns with opt out. Specifically, a commenter with concerns about sharing patients' mental health and substance use information recommended that CMS adopt an opt in process, including a requirement for patients to provide written authorization before such information is accessible through the Provider Access API. The commenter explained that there are laws in place requiring a written authorization from a patient to disclose mental health and substance use information. Another commenter also recommended that CMS align requirements for the Provider Access API opt out approach with consent requirements under 42 CFR part 2. A commenter further stated their belief that most patients would choose to opt into the Provider Access API if they are adequately informed of their rights and the potential for API data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to our proposed rule for a full discussion of why we proposed an opt out patient permission framework (87 FR 76259). As discussed elsewhere, we are finalizing a requirement that impacted payers must provide patients with plain language information about the Provider Access API, including how to opt out of data sharing, in order to help maximize patient control. This requirement should ensure that patients, including those with low health literacy or limited English proficiency, are aware of their rights and have the opportunity to make an informed decision about whether or not to allow payers to share their data with their providers through the Provider Access API. We further remind readers that all data sent and received via the Provider Access API must still be handled consistent with all other applicable laws and regulations regarding disclosure of these data. For instance, rules of confidentiality for patient records associated with mental health or substance use disorder, such as 42 CFR part 2, which may require patient consent to share with providers, will still apply.
                    </P>
                    <HD SOURCE="HD3">ii. Interaction With HIPAA</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that a process requiring patient permission for data sharing via the Provider Access API is not necessary because the HIPAA Privacy Rule permits PHI disclosure without patient permission under certain circumstances. Specifically, they reasoned that patient permission is not necessary if the PHI disclosed via the Provider Access API falls within the scope of HIPAA treatment, payment, and operations (TPO) disclosures, and recommended that CMS limit the data shared via the Provider Access API to the scope of permitted TPO disclosures. In support of their recommendation, these commenters noted that requiring an opt out process could be confusing and cumbersome to patients, negatively affect patient care, and would conflict with Federal and state laws (including the HIPAA statute). In a similar vein, commenters stated that CMS should rely on the HIPAA Privacy Rule requirements instead of requiring an opt out process, and a commenter suggested that CMS require impacted payers to include the Provider Access API exchange in their HIPAA Notices of Privacy Practices (NPP). Another commenter recommended that CMS make it clear that payers may still share certain patient health information with providers if it falls under the scope of a TPO disclosure, even when a patient elects to opt out of data sharing. Multiple commenters recommended that CMS provide additional guidance as to whether the Provider Access API is to be used for purposes beyond treatment, and indicated that providers should be able to access payer data for other purposes permitted under the HIPAA Privacy Rule, such as payment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that there are those who believe that an opt out patient permission process is not necessary, given existing HIPAA Privacy Rule provisions that permit PHI disclosure without an individual's authorization under certain circumstances. However, we emphasize that by virtue of this final rule, impacted payers would be required to disclose any PHI specified within the content standards for the Provider Access API, if the applicable requirements of this rule were met. That disclosure would be permitted under the HIPAA Privacy Rule as “uses or disclosures that are required by law,” 
                        <SU>68</SU>
                        <FTREF/>
                         rather than as a permitted TPO disclosure. Required by law disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard,
                        <SU>69</SU>
                        <FTREF/>
                         thereby ensuring that all content required by our Provider Access API policy may be disclosed. Because our policies would potentially give providers access to more than what would have been considered to be the minimum necessary PHI under the HIPAA Privacy Rule for certain purposes (for example, administrative data in the USCDI that would not be used for treatment purposes), we are requiring impacted payers to give patients or their personal representatives an opportunity to opt out so that they have some control over whether or not to share this additional data with their provider(s). We believe that patients should control their own data to the extent possible and with an opt out approach to data sharing, we are giving patients this opportunity. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.512(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.502(b)(2)(v).
                        </P>
                    </FTNT>
                    <P>
                        We emphasize that the opt out process described here only applies to the Provider Access API policies in this final rule. That is, the requirement for impacted payers to share individual 
                        <PRTPAGE P="8810"/>
                        claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service on or after January 1, 2016, with in-network providers who have a treatment relationship with the patient. If a patient or their personal representative opts out under our policy, then the impacted payer should not share these data with a provider who requests it under this policy. However, there may be other permissible bases for payers and providers to share data, such as under the HIPAA Privacy Rule's permitted uses and disclosures to carry out TPO. Patients or their personal representatives do not have the ability to opt out of a payer or provider using the API itself as a mechanism for sharing data under such bases for disclosure.
                    </P>
                    <P>We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Provider Access API policy. For instance, a payer may be permitted to disclose clinical data included in a content standard at 45 CFR 170.213 with a health care provider for treatment purposes under 45 CFR 164.506(c)(2). If that disclosure is permissible, a patient opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API to make that disclosure. In addition, there may be permissible bases for sharing data outside the scope of our Provider Access API policy. As an example, payers may be permitted to disclose clinical data that is not included in a content standard at 45 CFR 170.213, such as information related to SDOH, under the TPO exception. Similarly, a patient or personal representative opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API as the mechanism to make that permissible disclosure.</P>
                    <P>Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out TPO. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual's request for a restriction. Where a covered entity agrees to a restriction, it is bound to it unless the restriction is subsequently terminated. We emphasize that the opt out process described in this final rule is specific to the Provider Access API policy and therefore is not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).</P>
                    <P>Payers should make these nuances clear to patients in their required educational resources, so that patients understand that their PHI may still be shared in some instances, even if they or their personal representative opts out of the Provider Access API policy.</P>
                    <HD SOURCE="HD3">iii. Interaction With Health Information Exchanges</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters noted that HIEs would be great partners for payers when implementing the Provider Access API, with one noting that they could be used to reduce the number of endpoints providers would need to query for patient information. Commenters suggested that because many providers already have connections to HIEs set up within their EHRs, HIEs could act as a conduit for the information impacted payers are required to make available. Furthermore, commenters stated that HIEs could make available patient clinical data beyond what is maintained by the payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that HIEs could be helpful partners for payers when implementing the Provider Access API and nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. As a commenter noted, HIEs have extensive experience and expertise with patient matching and attribution, as well as with various consent models. We additionally agree that provider participation in an HIE can reduce the number of endpoints they would need to query for care coordination and treatment. We further encourage payers to look to HIEs or HINs as models for implementing a legal framework for data exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple other commenters recommended that CMS both explain and reexamine its interpretation of 42 CFR 431.306(d) and 457.1110(b) to prohibit Medicaid and CHIP programs from releasing beneficiary information to outside sources without first obtaining permission from the beneficiary or their personal representative. The commenters stated that CMS's current interpretation would effectively prohibit Medicaid agencies from participating in HIEs for Provider Access API and TPO purposes. The commenters stated that CMS should consider expanding this to include out-of-network providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7) of the Act, which our regulations at 42 CFR part 431, subpart F, implement, requires that a state's Medicaid plan provide safeguards which restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants' and beneficiaries' information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIP programs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to develop and maintain the required Provider Access API would be directly related to the administration of the state plan, because sharing beneficiary data through the Provider Access API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). Access to beneficiary data could help a provider better manage a beneficiary's total care because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent orders for, or the provision of, duplicative services. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency's capability for effective administration of the program.
                    </P>
                    <P>
                        The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid or CHIP applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source, or disclosing that applicant's or beneficiary's data safeguarded under 42 CFR 431.305. There is no requirement for a state Medicaid or CHIP agency to obtain permission from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to an enrolled Medicaid or CHIP provider because enrolled providers are not outside sources as described at 42 CFR 431.306(d). Enrolled Medicaid and CHIP 
                        <PRTPAGE P="8811"/>
                        providers are part of a state's Medicaid and/or CHIP FFS programs because they are contracted to support the agency's administration of its Medicaid or CHIP state plan. Specifically, an enrolled Medicaid or CHIP provider has a provider agreement with the Medicaid or CHIP agency to provide Medicaid or CHIP benefits and services under the state plan. Thus, the state Medicaid agency could share Medicaid or CHIP beneficiary information with enrolled providers for purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.
                    </P>
                    <P>Similarly, state Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the state Medicaid or CHIP agency has contracted to support the agency's administration of its Medicaid or CHIP state plan. Such contractors would not be considered “outside sources” because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan, such as case management and long-term services and supports for Medicaid or CHIP beneficiaries. Thus, if a state Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state's Medicaid or CHIP program, such as developing and maintaining the required Provider Access API, the HIE would not be considered an “outside source” and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for the purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.</P>
                    <P>In addition, to receive beneficiaries' information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid or CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, the Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency's contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid or CHIP agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations at 42 CFR part 431, subpart F), including but not limited to—</P>
                    <P>• Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and</P>
                    <P>• Not disclosing data to an outside source, such as providers that are not enrolled with the state Medicaid or CHIP agency, and that might be participating in an HIE, without prior permission from the individual in accordance with 42 CFR 431.306(d).</P>
                    <HD SOURCE="HD3">iv. Opt Out Process Design</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters provided thoughts about the implementation of the proposed opt out requirement. Multiple commenters suggested that CMS require a standardized opt out process to improve the patient and provider experience. A commenter expressed concern that the proposed implementation flexibility could be difficult for patients to navigate, while another commenter requested clarification on what opting out and opting back in means.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that it is important to make it easy for patients or their personal representatives to opt out of data sharing. However, it is also important to give payers flexibility in how they implement the opt out process required by this rule. We recognize that payers' approaches may vary depending on their systems, capabilities, and specific enrollee population. Requiring a specific process could impose unnecessary burden on payers. We remind readers that regardless of what process payers choose, a patient or their personal representative must have the ability to change their data sharing permission at any time. For example, if a patient or their personal representative previously opted out of having their data shared under the Provider Access API policy, they should be able to reverse this decision, effectively choosing to opt back into having their data shared under the Provider Access API policy. We additionally note that each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt out of data sharing under the Provider Access API for that person. No data should be shared about any patient that has opted out (or whose personal representative has opted out), regardless of whether another patient covered under the same benefits has chosen to not opt out. We will continue to monitor implementation of the Provider Access API opt out requirement to ensure payers' opt out processes for the Provider Access API are easy and intuitive for patients or their personal representatives to use.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters recommended that CMS include several additional, explicit requirements related to the Provider Access API opt out process. Multiple commenters also recommended requiring or permitting payers to incorporate the opt out process into their existing platforms and communications, including patient portals, payers' websites, and within payers' regular communications with patients. A commenter encouraged CMS to collaborate with interested parties to develop a single platform for patients to give permission for data sharing.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we are not requiring impacted payers to incorporate their opt out processes into their existing platforms and communications, we generally expect that that would result in the least amount of burden on payers and patients. There are solutions available that could be leveraged to manage permissions across payers, such as HIEs. We encourage impacted payers to investigate a variety of options to determine the solution that is best for them and their patients.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters made recommendations related to the accessibility of the opt out process. They recommended that CMS require impacted payers to provide options to patients for opting out of data sharing that are accessible to patients with varied technological literacy (that is, via mail, fax, and phone). A commenter recommended that opt out information be available for the Provider Access API in multiple languages to reduce disparities and barriers to patients' understanding of the opt out process. Another commenter recommended that CMS establish clear expectations for how payers should accommodate patients who may have difficulty accessing the opt out process or that CMS should track the extent to which patients encounter difficulties with opting out of data sharing. A commenter further recommended that payers collect patients' opt out elections at the point of treatment, so that it is clear which provider(s) have access to the patient's data via the Provider Access API policy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that payers should make efforts to 
                        <PRTPAGE P="8812"/>
                        ensure their patients or their personal representatives have the opportunity to opt out of data sharing under the Provider Access API policy and should be accommodated accordingly. These accommodations certainly include accounting for varied technology literacy and language barriers (see section II.B.3.c.ii. of this final rule for a discussion on plain language and existing requirements to make information accessible in other languages or formats). However, we do not want to be overly prescriptive to payers, as we believe they would know best how to accommodate their particular patient population. We disagree that payers should collect patient opt out elections at the point of treatment because we intend for these data to be available to the provider before patient appointments, and such practices are also outside the scope of a provider's role. We therefore intend to monitor patient experience and payer compliance with the opt out process and will consider our observations through this monitoring for future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended implementing processes for payers to notify providers of patients' election to opt out of the Provider Access API data exchange. A commenter identified some potential implementation challenges for providers, including that tracking patient permission would be challenging and that the opt out approach could create segmented data captures and multiple workflows. Another commenter flagged that CMS should not rely on physicians to educate patients on the intricacies of APIs, instead encouraging CMS to provide standardized language and guidelines to payers around how the process to opt out will be communicated to patients and the process for collecting and communicating opt outs to physicians.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we are not requiring impacted payers to notify providers of their patients' election to opt out of the Provider Access API data exchange, we agree that notification can increase the utility of the Provider Access API for providers. We remind readers that we are not requiring providers to track patient data sharing permission, educate patients about their data sharing options, or utilize the Provider Access API at all. However, we believe that giving providers access to more patient data will benefit the care that they provide, and we encourage them to adjust their workflows and work with their EHR developers to take advantage of the data availability through this new mechanism.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that it will take time for payers to process opt out requests from patients or their personal representatives who choose to opt out of having their data shared after enrollment. Another commenter suggested that patients should be able to record their permission through multiple channels (for example, OAuth 2.0, portal access, and the FHIR consent profile). A commenter also stated that payers may have to design related processes to allow patients to opt in to sharing of sensitive information that adhere to state or local privacy laws. A commenter further sought guidance on whether specific consent language would be required for patients or their personal representatives to opt in and whether an opt in election may be included in the HIPAA authorization form or other enrollment materials.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Payers will have flexibility in how they process patient data sharing permission and the channels that patients may use to make their election. We caution, however, that any such opt out channels should be both optimally accessible to patients or their personal representatives and not onerous for them to navigate. Part of managing an opt out process will include cognizance of other laws that may restrict data sharing, such as state privacy laws. In fact, if other applicable law requires an opt in permission for data sharing, payers may integrate both the Provider Access API opt out and other permission gathering processes to simplify patients' ability to control their data, to the extent permitted by law. Finally, regarding the commenter seeking specific consent language for opt in and clarification related to leveraging the HIPAA authorization form for this purpose, we emphasize that this final rule finalizes an opt out framework for the Provider Access API, not an opt in. We further note that compound HIPAA authorizations are generally prohibited, per 45 CFR 164.508(b)(3).
                    </P>
                    <HD SOURCE="HD3">v. Opt Out Timeframes</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that patients or their personal representatives should be allowed to opt out at any time. Other commenters supported payers providing an option to opt out at a certain time, such as at the time of enrollment. A commenter recommended that CMS allow payers 30 days to process a patient's request to opt out and stop sharing the patient's data via the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that patients or their personal representatives should be able to opt out of data sharing under the Provider Access API policy at any time and we are requiring impacted payers to give their patients the opportunity to do so. As discussed in section II.B.3.c. of this final rule, no later than one week after the start of coverage and annually, patients will need to be given information about their opt out rights and instructions both for opting out. We remind readers that “start of coverage” is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. of this final rule for discussion of these differences. We do not agree that the opt out option should be time-limited, as that reduces patient control over their health data.
                    </P>
                    <HD SOURCE="HD3">c. Patient Educational Resources Regarding the Provider Access API</HD>
                    <P>
                        To help patients understand the implications of the opt out provision for the Provider Access API, we proposed to require impacted payers to disseminate certain educational resources to their patients. We proposed that those resources would include information about the benefits to the patient of API data exchange, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. We proposed that payers would have to provide this information, in non-technical, simple, and easy-to-understand language, before the first date on which the payer makes patient information available through the Provider Access API, at the time of enrollment and annually thereafter. We also proposed that payers would be required to make this information available at all times, in an easily accessible location on payers' public websites. We did not propose to require this information to also be distributed to patients' personal representatives. However, we highly encourage impacted payers to do so, especially if distributing other materials to personal representatives is typical. We also did not propose specific text or format for this information, but requested suggestions and comments on whether required content or format would be beneficial or burdensome. In particular, we sought comments on language explaining how patient data that is shared through the Provider Access API could be used. We anticipated that payers would want to include this information in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we requested comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also requested comment on whether 
                        <PRTPAGE P="8813"/>
                        a requirement to provide this information at the time of enrollment and annually is appropriate, or whether we should require payers to share this information more frequently.
                    </P>
                    <P>We believe it is important to honor patient privacy preferences. Offering patients educational resources about their right to opt out of the Provider Access API data sharing is thus fundamental to empowering patients with respect to their data.</P>
                    <P>As discussed in more detail, we are finalizing a modification to these proposals, that impacted payers must provide this information to patients no later than one week after the start of coverage. “Start of coverage” is defined differently, as applicable, for each type of impacted payer and we refer readers to section II.C.3.c.i. of this final rule for discussion of these differences.</P>
                    <HD SOURCE="HD3">i. Dissemination</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the proposed requirement for payers to disseminate patient educational resources and made recommendations for communicating with, or sending information to patients. These recommendations include disseminating educational resources through existing patient portals, letters, text messages, and information posted on websites, in handbooks, and by mail.
                    </P>
                    <P>Conversely, a commenter recommended that CMS not require physical materials be sent annually to patients. The commenter recommended that payers should only send hard copies to patients who have opted out of data sharing. However, another commenter stated that separate patient resources for the Provider Access API are not necessary at all. A commenter additionally stated that many plan renewals do not actually generate patient-visible paperwork, forms, or formal documents of any sort and provided examples for how frequently sharing patient resources currently occurs. A commenter further stated that payers should have the flexibility to communicate with their members in a manner consistent with a set format and content for consistency and clarity.</P>
                    <P>
                        <E T="03">Response:</E>
                         We emphasize that impacted payers can indeed use their existing processes for producing patient-facing resources and will be permitted to send their patient education resources through the communication channels they think are most effective for reaching their patients, including emails, messages through a payer portal, or physical mail. It is not our intention to overburden payers, and thus we do want to be overly prescriptive in a way that that will unduly disrupt how they currently communicate with their patients. We disagree that only patients who have opted out of data sharing should receive these resources. Under our policies, patients may choose to change their data sharing permission at any time and we thus believe that they should remain maximally informed of their choices.
                    </P>
                    <P>We are also finalizing a modification to the proposed rule regarding payer deadlines, to give payers more clarity and an appropriate amount of time to meet these requirements, as well as to align with policies we are finalizing for the Payer-to-Payer API (see section II.C.3.c.i. of this final rule). Specifically, payers will be required to provide patients, no later than one week after the start of coverage, information about the benefits of API data exchange with their providers, their opt out rights, and instructions for both for opting out of data exchange and for opting in after previously opting out. This timeframe is intended to provide a reasonable amount of time after a payer receives confirmation that a patient will be enrolled in coverage with them. As further discussed in section II.C.3.c.i., to ensure feasible timeframes, we are finalizing deadlines to account for situations when coverage starts prospectively or retroactively for MA plans and QHPs issuers on the FFEs and retroactively for Medicaid and CHIP.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter. A commenter stated that educational resources could also come from providers at patient interactions. Other commenters expressed that CMS's requirements should not add burden to providers or interfere with their clinical workflow. A commenter recommended that CMS not require Medicaid agencies to provide information on the Provider Access API opt out policy more frequently than at member enrollment and annually. The commenter stated that it would be resource intensive and would require new workstreams and member outreach processes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support of our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter (though we are finalizing a modification to this proposal, as explained above). We did not propose to require any role for providers, as we agree this would increase their administrative burden. We also agree with commenters that providing these resources more frequently would indeed increase burden, which is why we did not propose for impacted payers to do so.
                    </P>
                    <HD SOURCE="HD3">ii. Content</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that CMS require payers to use clear and plain language and ensure the opt out policy is prominent.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters' sentiments and thus proposed that patients should be able to easily understand the patient education resources. In response to both these comments and comments on our opt out proposals, as well as for consistency with other policies, we are finalizing this rule slightly differently from how it was proposed. We had proposed that impacted payers provide patient education resources in “non-technical, simple, and in easy-to-understand language,” but our finalized requirement is that they use “plain language.” This change is not intended to alter that the educational information be non-technical, simple, and easy-to-use, but to make clear that we encourage impacted payers to follow the Federal Government's plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies to use clear government communication that the public can understand and use. That statute only applies to Federal Government agencies, but the plain writing guidance 
                        <SU>70</SU>
                        <FTREF/>
                         that has been developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We note that providing these patient educational resources is a separate requirement from the requirement to create an NPP under the HIPAA Privacy Rule.
                        <SU>71</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             General Services Administration (n.d.). Federal plain language guidelines. Retrieved from 
                            <E T="03">https://www.plainlanguage.gov/guidelines/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             Department of Health and Human Services (n.d.). Notice of Privacy Practices for Protected Health Information. Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/privacy-practices-for-protected-health-information/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed concern about language access, while another recommended CMS set inclusivity requirements, based on a payer's patient population, for translating into languages other than English. Multiple commenters recommended that notices about the Provider Access API be focus group tested, written in accurate but positive language (so as not to unduly discourage participation), and translated into the required threshold languages for the coverage area.
                        <PRTPAGE P="8814"/>
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Impacted payers may already be required to provide plain language resources in languages other than English, per 45 CFR part 92, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.
                    </P>
                    <P>Additionally, this rule does not affect standards already in place for specific payers on state or Federal levels. For example, 45 CFR 156.250 requires QHP issuers on the FFEs to provide information in accordance with the accessibility standards for individuals with disabilities and individuals with limited English language proficiency at 45 CFR 155.205(c). Other impacted payers might have their own standards for accessible patient-facing resources, as well, that would not be affected by this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended, for ease of readability, that resources or notices be written at a certain grade level. Multiple commenters recommended that CMS amend the patient resources proposal to require impacted payers to write resources at a fourth-to-sixth grade reading level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we agree that these resources need to be understandable, we do not believe that it is prudent to establish a specific “grade level” requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how it is used. Furthermore, edits that are made to make text score at a lower grade level can produce choppy text that lacks cohesion.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter did not support the development of patient education resources that may be duplicative or confusing to patients, while another did not support the proposal for separate patient outreach and education if the data sharing under the Provider Access API is permitted under the HIPAA Privacy Rule's TPO exception.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to section II.B.3.b.ii. of this final rule for a full discussion of the HIPAA Privacy Rule's applicability and why we are requiring an opt out policy for the Provider Access API. We believe that plain language educational resources will inform rather than confuse patients. We encourage payers to explain to patients that not opting out of data sharing would not limit or negatively affect their rights under the HIPAA Privacy Rule. Rather, it is an opportunity for them to control where their data are shared under the policies of this final rule. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should also consider their obligations under the HIPAA Privacy Rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters recommended that CMS require additional details from payers about their opt out process for the Provider Access API. A commenter stated patients should receive detailed communications that include the potential benefits and harms of sharing versus not sharing this information, including the potential impact on quality and timeliness of care. Commenters further recommended that resources include information on privacy and security, moving data to a third-party app, and guidelines for patient-provider dialogue on consent.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As explained, we did not want to be overly prescriptive for the specific language used for the patient resources, but we did propose that they include patient instructions for opting out of data sharing and controlling their permission. We specifically proposed that the patient education resources include information about the benefits of API data exchange. In addition, impacted payers may, if they choose, include reasonable and objective information about any risks to data sharing. However, the purpose of the information in the educational resources, regardless of the particular content, should be to inform patients. We believe that patients educated with accurate information will realize the benefits of data sharing via the Provider Access API and most will not opt out.
                    </P>
                    <P>We agree that plain language resources should include information about privacy and security, in order to give patients an informed view of how the Provider Access API works. It is also reasonable and acceptable for payers to bundle or combine the educational resources about the Provider Access API with the educational resources about the Patient Access and Payer-to-Payer APIs, discussed in sections II.A. and II.C. of this final rule, to give patients a holistic view of how our interoperability policies work together to improve data exchange.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters recommended that CMS partner with ONC to develop templates and content for these educational resources, which impacted payers could use to meet this requirement. Many commenters recommended that CMS work with the health care community and patient advocates to develop language on the benefits and risks of data exchange. Commenters also recommended that CMS work with industry to develop and disseminate educational resources by creating a web page dedicated to interested party-specific newsletter inserts, holding CMS open door virtual forums, and using other methods to communicate regulatory and implementation updates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We intend to continue working with Federal and industry partners to increase patient engagement in a way that both protects their autonomy and enables the sharing of the data to improve their health care. Based on feedback, we intend to develop additional outlines or templates for patient education resources.
                    </P>
                    <HD SOURCE="HD3">d. Provider Resources Regarding the Provider Access API</HD>
                    <P>We proposed to require impacted payers to develop non-technical and easy-to-understand resources for providers about the Provider Access API. We proposed that those resources would have to include information about the process for requesting patient data from payers via the Provider Access API and how to use the payer's attribution process to associate patients with the provider. We proposed that impacted payers provide these resources to providers through the payer's website and other appropriate provider communications, such as annual contract updates or handbooks. Non-technical resources will help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API. We requested comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking, the specific content of these educational resources about the Provider Access API.</P>
                    <P>As discussed in more detail, we are finalizing this proposal, with a modification that provider resources be in plain language.</P>
                    <HD SOURCE="HD3">i. Dissemination</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for requiring impacted payers to make these resources easily available on a payers' website, in contracts, and in provider handbooks. However, other commenters sought clarification on what “other appropriate provider communications” are and whether existing provider communication channels can be used to provide these resources. A commenter stated that it is unreasonable to expect 
                        <PRTPAGE P="8815"/>
                        providers and their staff to access each payers' website to obtain the payers' specific resources and they do not believe this will happen in a reliable manner. Other commenters stated that the resources should be incorporated into a clinical workflow or EHRs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While the provider resources must be available on the payer's website, we are also requiring impacted payers to send those resources directly to providers through other appropriate channels. We encourage payers to use existing methods of communication by which providers expect to receive information from payers. We use the term “other appropriate provider communications” to provide payers with flexibility, but that term includes existing communication channels. For example, 42 CFR 422.202 requires MA organizations to provide to participating physicians written notice of rules of participation, including terms of payment, credentialing, and other rules directly related to participation decisions. The Provider Access API resources can be disseminated along with such resources.
                        <SU>72</SU>
                        <FTREF/>
                         While payers are welcome to use the Provider Access API to make those resources available, they would have to develop an operable solution. Furthermore, if a provider needs guidance to access the Provider Access API, requiring a connection and query would not be useful.
                    </P>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.202(a)(1).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Content</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the proposal for impacted payers to disseminate provider-facing resources, particularly with instructions for attributing patients to a provider.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters support for this requirement. As finalized, payers will be required to include information about the payer's process to attribute patients to a particular provider. We also highly recommend that payers include contact information for provider assistance. To be consistent with our revision to the patient education resources policy, but also being clear that we have not altered the intent, we are finalizing regulatory text slightly different than what we had proposed, to require provider education resources in “plain language,” as opposed to our proposed “non-technical, simple, and in easy-to-understand language.”
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended more technical education resources than we proposed because of the technical nature of API data exchange. A commenter suggested that the resources include information about the IGs, links to the payer's technical documentation and contact information for assistance with the Provider Access API. Another commenter warned that the educational resources need to be better defined, because they believe that the information we describe will be more appropriate for EHR vendors than providers. In fact, another commenter stated that it may be more appropriate for EHR and practice management system vendors to provide education resources that offer greater specificity about how data are integrated into provider data systems and workflows.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While payers will have to include instructions for accessing patient data, we disagree with the recommendation that payers include more technical documentation. We do not believe that most providers will be interested in the specific implementation details of the API, but will rely on their technology vendor. We remind payers that, per the final requirements in the CMS Interoperability and Patient Access final rule, they are required to make technical information about their Patient Access APIs available by posting directly on their website.
                        <SU>73</SU>
                        <FTREF/>
                         We are finalizing this requirement by reference for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, as well. References or links to that material would be entirely appropriate to include in the required provider resources. EHR and practice management vendors also have a role to play in educating providers about the functionality of their particular system. However, only payers will be able to offer provider specific details about their Provider Access API and the process for attributing patients.
                    </P>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.119(d), 431.60(d), and 457.730(d) and 45 CFR 156.221(d).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters suggested that CMS require using language regarding limitations related to disclosures of sensitive conditions that are subject to 42 CFR part 2 and disclosures to minors.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Though we are not requiring it to be included in the provider resources, payers should adequately inform providers of what data are and are not available through the Provider Access API. Providers should be aware of what they can expect to receive in response to a request, whether that is because of the data content requirements, payer maintenance policies, or privacy limitations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested that CMS develop educational resources that impacted payers could disseminate to their providers to ensure consistency and that providers are aware of any reporting protocols for payer non-compliance. A commenter added that these requirements and related guidance should be posted on CMS provider web pages and print publications. Multiple commenters recommended that CMS consult with Federal partners at ONC, the Health Resources and Services Administration (HRSA) and the Agency for Healthcare Research and Quality (AHRQ), and the provider community in order to understand their educational needs and how best to promote the resources. A commenter recommended that CMS provide additional guidance on the education and training efforts to provider specialties who are lagging the industry in interoperable technology adoption.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Based on comments we received, we intend to provide general guidelines to impacted payers about what this final rule requires to be disseminated to providers, which may include information on potential best practices. However, unlike the patient-facing educational resources described previously, we expect that provider resources could vary significantly between payers. Payers will have different processes to allow providers to request data via the Provider Access API and policies for patient attribution to explain to their providers. Therefore, there is less benefit to standardized templates or content for these resources. We provided links to resources for APIs to support payers implementing provisions of the CMS Interoperability and Patient Access final rule (85 FR 25510) 
                        <SU>74</SU>
                        <FTREF/>
                         and we intend to identify similar resources for health care providers for this final rule. We will continue to work with our partners to ensure providers can access patient data, regardless of the technology they use. Requiring an API that can be accessed with systems other than CEHRT is a step toward that goal, and payer-developed resources should address all the ways providers could interact with the Provider Access API.
                    </P>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             Centers for Medicare and Medicaid Services (n.d.). Best Practices for Payers and App Developers. Retrieved from 
                            <E T="03">https://www.cms.gov/files/document/best-practices-payers-and-app-developersupdated21023.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Extensions, Exemptions, and Exceptions</HD>
                    <P>
                        See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Provider Access API for state Medicaid and CHIP FFS programs and exceptions for the Provider Access API for QHP 
                        <PRTPAGE P="8816"/>
                        issuers on the FFEs (this was also addressed in the proposed rule at 86 FR 76279).
                    </P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="540">
                        <GID>ER08FE24.001</GID>
                    </GPH>
                    <GPH SPAN="1" DEEP="540">
                        <PRTPAGE P="8817"/>
                        <GID>ER08FE24.002</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <HD SOURCE="HD3">5. Final Action</HD>
                    <P>
                        After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             
                            <E T="03">See</E>
                             Table H1 for which standards are required for the Provider Access API.
                        </P>
                    </FTNT>
                    <P>• Impacted payers must implement and maintain a Provider Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.</P>
                    <P>• Impacted payers are not required to use OpenID Connect Core at 45 CFR 170.215(e)(1) for the Provider Access API.</P>
                    <P>• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Provider Access API.</P>
                    <P>• Impacted payers are not required to share unstructured documentation related to prior authorizations via the Provider Access API.</P>
                    <P>• Impacted payers are required to provide educational resources to patients no later than one week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment.</P>
                    <P>• The educational resources that impacted payers are required to provide to patients and providers are described as “plain language” rather than in “non-technical, simple, and in easy-to-understand language.”</P>
                    <P>See further discussion later for exact details of the final requirements for impacted payers.</P>
                    <P>We are finalizing that beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS Programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Provider Access API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), SMART App Launch IG at 45 CFR 170.215(c)(1), and Bulk Data Access IG at 45 CFR 170.215(d)(1).</P>
                    <P>We are finalizing that, by the deadlines, impacted payers must make available upon request from an in-network provider, via the Provider Access API, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations (excluding those for drugs) that the payer maintains no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:</P>
                    <P>• The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process;</P>
                    <P>• The patient does not opt out of the Provider Access API; and</P>
                    <P>• Disclosure of the data is not prohibited by law.</P>
                    <P>The required prior authorization information is:</P>
                    <P>• The prior authorization status;</P>
                    <P>• The date the prior authorization was approved or denied;</P>
                    <P>• The date or circumstance under which the prior authorization ends;</P>
                    <P>• The items and services approved;</P>
                    <P>• If denied, a specific reason why the request was denied; and</P>
                    <P>• Related structured administrative and clinical documentation submitted by a provider.</P>
                    <P>We are finalizing that impacted payers are required to make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.</P>
                    <P>We are finalizing that impacted payers must establish and maintain an attribution process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API.</P>
                    <P>We are finalizing that, by the deadlines, impacted payers must establish and maintain a process for patients to opt out of data exchange via the Provider Access API and to change their permission at any time. We are finalizing that this process must be made available before the first date on which the payer makes patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer.</P>
                    <P>
                        We are finalizing that, by the deadlines, impacted payers provide educational resources in plain language to their patients about the Provider Access API. Those resources must include information about the benefits of API data exchange with providers, patients' opt out rights, and instructions for both opting out of data exchange and for subsequently opting in. Impacted payers must make this information available to patients before the first date on which the payer makes their 
                        <PRTPAGE P="8818"/>
                        information available via the Provider Access API, no later than one week after the start of coverage, and at least annually. These resources must also be available in an easily accessible location on payers' public websites. We remind readers that “start of coverage” is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. for discussion of these differences.
                    </P>
                    <P>We are finalizing that, by the deadlines, impacted payers must provide on their website and through other appropriate provider communications, information in plain language explaining the process for requesting patient data using the Provider Access API. The resources must include information about how to use the payers' attribution process to associate patients with their providers.</P>
                    <P>These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities (excluding NEMT PAHPs), and QHP issuers on the FFEs at the CFR sections listed in Table C1.</P>
                    <HD SOURCE="HD3">6. Statutory Authorities for Provider Access API</HD>
                    <P>We received no public comments on the statutory authorities for our Provider Access API policies.</P>
                    <HD SOURCE="HD3">a. Medicare Advantage Organizations</HD>
                    <P>For MA organizations, we are finalizing these Provider Access API requirements under our authority at sections 1856(b)(1) of the Act to promulgate regulations that adopt standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)) of the Act to adopt new terms and conditions for MA organizations that the Secretary finds “necessary and appropriate.” Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits. As noted in this section of this final rule, these regulations implement this requirement by requiring implementation of an API that will make available data to improve the provision of benefits. The Secretary also has authority under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute.</P>
                    <P>In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Our policy for MA organizations to implement and maintain a Provider Access API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access API policy, which will support sharing claims, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations (sections II.B.2. and II.B.3. of this final rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this final rule), will give providers tools to support continuity of care and care coordination for enrollees. Were a provider able, through a Provider Access API established by an MA organization, to gather information for their patient, the provider potentially could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider will be able to ensure continuity of care if they are able to access relevant health information for the patient from the MA organization in an efficient and timely way. A Provider Access API could support this; thus, the policy will carry out and be consistent with the Part C statute.</P>
                    <P>This policy will complement and align with MA organization obligations at 42 CFR 422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of information that supports effective and continuous patient care. A Provider Access API may increase the efficiency and simplicity of administration. It will give providers access to a significant amount of their patients' information with limited effort, and it could reduce the amount of time needed during provider visits to establish a patient's prior history, which could introduce efficiencies and improve care. These policies are also expected to allow for better access to other providers' prior authorization decisions, which could give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. Ultimately, we anticipate that sharing patient information will ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization and higher patient satisfaction. In addition, the policy that MA organizations make available educational resources and information will increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for providers to access patient information. Thus, the Provider Access API will be necessary and appropriate for the MA program and consistent with existing requirements.</P>
                    <HD SOURCE="HD3">b. Medicaid and CHIP</HD>
                    <P>Our finalized requirements in this section for Medicaid FFS and Medicaid managed care plans fall generally under the authority in the following provisions of the statute:</P>
                    <P>• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan;</P>
                    <P>• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and</P>
                    <P>• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.</P>
                    <P>The final Provider Access API policies are authorized under these provisions of the Act because they will ensure that states are able to ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The policies are expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients.</P>
                    <P>
                        In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are 
                        <PRTPAGE P="8819"/>
                        directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements for sharing applicant and beneficiary data at 42 CFR 431.306.
                    </P>
                    <P>Our finalized policy, that the data described in this section of the final rule be shared via the Provider Access API, is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The Provider Access API data sharing policy is related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, a provider can better manage a patient's total care when they have access to more of that patient's data because the data will provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. More details about how the policies will be implemented in a manner consistent with state Medicaid requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2. of this final rule.</P>
                    <P>Requiring states to implement a Provider Access API to share data with enrolled Medicaid providers about certain claims, encounter, and clinical data, including data about prior authorization decisions, for a specific individual beneficiary, may improve states' ability to ensure that care and services are provided in a manner consistent with simplicity of administration, and to cover services more efficiently. We remind states that “enrolled Medicaid providers” includes managed care plan providers, per 42 CFR 438.602(b). This Provider Access API will enable Medicaid providers to access beneficiary utilization and authorization information from the state or managed care plan(s) prior to an appointment or at the time of care, and that, in turn, should enable the provider to spend more time on direct care. The policy will support efficient and prompt delivery of care as well, which will be in beneficiaries' best interests. These policies are also expected to give providers better access to prior authorization decisions for care provided by other enrolled Medicaid providers, which will give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. This may also facilitate easier and more informed decision-making by the provider and should therefore support efficient coverage decisions in the best interest of patients. The Provider Access API is expected to make available a more complete picture of the patient to the provider at the point of care, which could improve the quality and efficiency of a patient visit. These outcome and process efficiencies may help states fulfill their obligations to ensure prompt access to services in a manner consistent with the best interest of beneficiaries, consistent with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. These analyses apply similarly to FFS and managed care programs and delivery systems, so we are exercising our authority to adopt virtually identical regulatory requirements for a Provider Access API for both Medicaid FFS programs and Medicaid managed care plans.</P>
                    <P>For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this policy will strengthen states' abilities to fulfill these statutory obligations in a way that will recognize and accommodate using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries.</P>
                    <P>When providers have access to patient utilization and authorization information from payers or other health IT systems, they may be able to provide higher quality care. Improving the quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. In addition, the information providers do collect will not be based solely on patient recall. This will save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider's EHR or practice management system, they can be leveraged as needed at the point of care by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient, and, ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API policies also align with section 2101(a) of the Act in that these proposals will improve coordination between CHIP and other health coverage. For these reasons, we believe this policy is in the best interest of the beneficiaries and within our long-established statutory authorities.</P>
                    <P>Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). More details about how the policies could be implemented in a manner consistent with these CHIP agencies' requirements are also discussed in section II.B.2. of this final rule. As discussed previously for Medicaid, giving CHIP providers access to attributed beneficiary data through the Provider Access API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share beneficiary information through the Provider Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.</P>
                    <HD SOURCE="HD3">c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>
                        For QHP issuers on the FFEs, we are finalizing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if an Exchange determines that making available such health plans through that Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe the benefits will outweigh any additional burdens this might impose on issuers. By using the finalized technologies, patients could experience improved health, payers could see reduced costs of care, and providers could see better compliance with care regimens. We also do not believe that premiums will significantly increase 
                        <PRTPAGE P="8820"/>
                        because some of the infrastructure necessary to implement the technology has been completed to comply with the CMS Interoperability and Patient Access final rule. Furthermore, QHP issuers on the FFEs might combine investments and staff resources from other programs for implementation efforts, avoiding the need to increase premiums.
                    </P>
                    <P>We believe that certifying only health plans that make enrollees' health information available to their providers via the Provider Access API is generally in the interests of enrollees. Giving providers access to their patients' information supplied by QHP issuers on the FFEs will ensure that providers are better positioned to provide enrollees with seamless and coordinated care and ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patient's more complete medical information could also maximize the efficiency of an enrollee's office visits. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.</P>
                    <HD SOURCE="HD2">C. Payer-to-Payer API</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>Having a patient's data follow them when they change payers can have a multitude of benefits for patient care. A payer receiving data when a new patient enrolls can better coordinate care and make more informed decisions. For instance, a payer can use the patient's data to determine whether they have a chronic condition or is undergoing current care that needs to be maintained. If necessary, patient data can give payers the information they need to assign a case manager or help the patient find providers in their new network. Maintaining a corpus of data ensures that the patient and their providers do not lose access to recent information that may be relevant to ongoing or future care.</P>
                    <P>Furthermore, because payers usually maintain a relationship with individual patients over time, they are uniquely positioned to collect and aggregate a patient's record. Whereas patients may have several providers who manage their care, they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. However, when a patient moves from one payer to another, both parties may lose access to that valuable data. Data exchange among payers, specifically, sending patient data from a patient's previous payer to their new one, is a powerful way to ensure that data follow patients through the health care system and improve care continuity. Electronic data exchange between payers will support payer operations and a patient's coverage transition to a new payer efficiently and accurately. Sharing health care data between payers also helps care coordination, care continuity, and allows patients to maintain access to their record over time.</P>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits of payers maintaining a longitudinal (meaning, long-term) record of their current patients' health information. If payers are at the center of the exchange, they can make information available to patients and their providers and can help a patient's information follow them as they move from provider to provider and payer to payer.</P>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we proposed and, in this rule are now finalizing regulations that require impacted payers (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a FHIR API to facilitate payer to payer data exchange. We are finalizing that proposal to require impacted payers to build a Payer-to-Payer API, with certain standards (as further described in section II.F.), that will facilitate patient data exchange at the start of coverage and with concurrent payers. We proposed, and are finalizing, a patient opt in policy for this data exchange. We proposed compliance dates in 2026 for the Payer-to-Payer API (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). However, in response to comments we are finalizing a modification to that proposal for the Payer-to-Payer API to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers. In addition, and also in response to comments, we are finalizing a modification to our proposal to only require impacted payers to exchange data with a date of service within 5 years of the exchange request.</P>
                    <P>
                        To support the implementation and maintenance of the Payer-to-Payer API, we are requiring certain standards and recommending certain IGs, as further discussed and in section II.G. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Payer-to-Payer API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program.
                        <SU>76</SU>
                        <FTREF/>
                         We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap.</E>
                        </P>
                    </FTNT>
                    <P>
                        In this section, we talk about data exchange between payers. When we refer to a patient's new payer, we mean the payer that a patient is newly enrolled with and the party responsible for requesting and receiving the patient's data. When we refer to the patient's concurrent payers, we signify the parties (two or more) that are providing coverage at the same time and are responsible for exchanging data with each other as discussed further in section II.C.3.c. When we refer to the patient's previous payer, we denote the payer that a patient has previously had 
                        <PRTPAGE P="8821"/>
                        coverage with and thus the payer responsible for sending the data to the new payer.
                    </P>
                    <P>Our payer to payer data exchange requirements discussed in this section involve transactions and cooperation between payers, which may include payers that are not subject to the requirements in this rule. We emphasize that each impacted payer is responsible only for its own side of the transaction. For instance, when an impacted payer is required to request patient data from another payer, it will have to do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the requirements, the impacted payer must share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident to the payer sharing the data). In this way, payers not subject to this regulation that implement a Payer-to-Payer API (or other IT functionality to request or receive information through the impacted payer's API) and their patients can also benefit from the data exchange.</P>
                    <P>We are exploring steps for Medicare FFS to participate in payer to payer data exchange and we encourage other payers that are not subject to these requirements to do the same. We intend to implement the Payer-to-Payer API capabilities for Medicare FFS in conformance with the requirements for impacted payers, as feasible. In the proposed rule, we sought comment on whether our proposals could be implemented as proposed for the Medicare FFS program, how we could apply each of the proposals, and whether there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We summarize the comments received and our responses in section I.D. of this final rule. We strongly encourage all payers that are not subject to the requirements of this rule to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may experience the benefits of such data exchange.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported our proposal to require data exchange via a Payer-to-Payer API. Commenters stressed the benefits to patients of maintaining an ongoing record when they change payers, which could result in better patient outcomes, especially for patients with chronic conditions. Commenters agreed that this API would improve interoperability, data exchange, and reduce administrative burden. Multiple commenters stated that the Payer-to-Payer API would be especially helpful to patients with concurrent coverage. A commenter stated that the assignment of primary care physicians could also be facilitated by the Payer-to-Payer API and that this could reduce care disruptions when changing payers. Another commenter acknowledged that investments made in payer to payer data exchange would benefit broader multi-payer alignment efforts, which are a key priority for improving quality, access, and value in health care. Another commenter stated that exchanging patient data from previous and concurrent payers would eliminate duplicative medical record requests from payers requiring providers to reapprove medical necessity, retry step therapy requirements, and reauthorize treatments.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters validating our statements in the proposed rule regarding the benefits of payer to payer data exchange. We agree that the benefits of payer to payer data exchange include both ensuring care continuity and that patients, providers, and future payers do not lose access to important health information. We are finalizing, with modification, the Payer-to-Payer API proposals as discussed in this section.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters opposed finalizing our Payer-to-Payer API proposals. They disagreed with our justification that payers should be the maintainers of a patient's longitudinal data. Another commenter cautioned that, as proposed, the Payer-to-Payer API would require payers to share a large amount of unnecessary data, which would make it difficult to effectively coordinate care. Instead, they suggested that by leveraging the Patient Access API, patients should have the responsibility to maintain their patient data using an app, or other solution of their choice. A commenter recommended that CMS separate the goal of creating longitudinal consumer health records from the goal of supporting consumer transitions between payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing comments, we agree that patients are in the best position to manage their health information, especially with the growing ecosystem of health apps and the availability of standardized Patient Access APIs. Some HIEs and health apps (which may also be TEFCA Participants and Subparticipants) may be able to gather data from payers, providers, and other sources to create a more comprehensive patient record than could be maintained by a payer. However, payers are uniquely positioned to collect and aggregate patient data, especially during coverage transitions. As we noted, patients may have several providers who manage their care, but they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. A payer to payer data exchange can facilitate care continuity by providing access to information about past treatments when a patient is moving from one payer to another. For example, that information could show payers that a patient has already demonstrated medical necessity or engaged in step therapy, which could ease the approval of a prior authorization request. Ensuring that payers have timely access to newly enrolled patients' data upon a patient transitioning payers can have a multitude of benefits for patient care leading to better-coordinated care, more informed decision-making, and minimize disruption in ongoing care. Therefore, to mitigate potential burden on impacted payers, while still establishing the Payer-to-Payer API as a means to support the creation and availability of a longitudinal record, as discussed, we are finalizing a modification to our proposal to only require payers to exchange data with a date of service within 5 years of the request. That modification means that payers will not be responsible for exchanging and maintaining a patient's entire health history dating to January 1, 2016.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters did not support the proposed Payer-to-Payer API and suggested alternatives to gain the intended benefits. A commenter noted that there are many industry solutions already being developed to facilitate the coordination of benefits between payers and recommended CMS continue to monitor and enable technical innovation in this area. Another commenter cautioned CMS to not view FHIR as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as proposed, payers would experience challenges if FHIR failed to reach widespread adoption and maturity. Another commenter stated that requiring the FHIR standard eliminates choice and leads to bias and further stated that other options may be better suited for a payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their suggestions, but FHIR APIs are the standard that the industry indicated has the greatest maturity and hence has been adopted by ONC. A variety of solutions will not lead to 
                        <PRTPAGE P="8822"/>
                        interoperability across the healthcare system. While payers already have processes in place for coordinating benefits, that coordination does not extend to transitions of care between payers, such as maintaining prior authorizations. Data exchange between payers can ensure that valuable patient information is not lost, such as prior authorization requests and approvals, which could make that transition more seamless. Requiring FHIR will get the healthcare industry to a more interoperable state, as that standard supports health data exchange in a standard, structured, but flexible format that can continue to advance and mature. Impacted payers are already required to use the FHIR standard for the Patient Access and Provider Directory APIs, and this final rule is meant to build on this existing policy. Also, we are extending the compliance dates for the Payer-to-Payer API to 2027. This delay to the compliance dates versus our proposal allows for additional time for implementation and IGs to be refined and matured to support the policies in this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding payer access to patient data. They worried that this could lead to patient risk profiling, increased prior authorization requirements, increased premiums and limits on coverage and access to care. They recommended that CMS prohibit impacted payers from using information sent from a previous payer to discriminate against a patient. A commenter stated that CMS should implement safeguards to ensure that the payer to payer data exchange does not encourage payers to make care decisions based on the patient's record. The commenter recommended that CMS explain that the provider is the director of medical care, and payers support the patient's care through payment and coverage of services. They suggested that large-scale consumer data exchange should be consumer-mediated and result in meaningful access to comprehensive data for care coordination among payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenters that patient information should not be used in an inappropriate manner. We remind payers that section 1852(b) of the Act states that an MA plan may not deny, limit, or condition the coverage or provision of benefits based on any health status-related factor described in section 2702(a)(1) of the Public Health Service Act.
                        <SU>77</SU>
                        <FTREF/>
                         Section 2705(a)(1) of the Public Health Service Act, which applies to QHP issuers on the FFEs, prohibits discrimination against individuals based on their health status-related factors. Similarly, section 2102(b)(1)(B)(ii) of the Act prohibits CHIP programs from denying eligibility for children with preexisting conditions. Finally, the overarching regulations at 45 CFR part 92 implementing section 1557 of the Affordable Care Act prohibit discrimination under any health program or activity receiving Federal financial assistance on the basis of race, color, national origin, sex, age, or disability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             Section 2702 of the Public Health Service Act referenced in section 1852(b) of the Act refers to what is now codified as section 2705 of the Public Health Service Act.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that implementation of a Payer-to-Payer API may increase provider burden with unintended downstream effects. A commenter discussed how the Payer-to-Payer API could lead to a negative impact on providers who may be required to ingest large amounts of data if payers maintain a longitudinal record back to January 1, 2016, that is also shared via the Provider Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Our modification to require impacted payers to exchange only 5 years of data via the Payer-to-Payer API will mitigate this possible issue for providers. By circumscribing the data to be exchanged by payers to only more recent data, providers are less likely to receive distant and irrelevant historical data via the Provider Access API. We acknowledge that not all of a patient's health information is going to be equally relevant to a particular provider. Therefore, providers should look for clinically relevant information and work with their EHR vendors on solutions to easily display the information most relevant to their practice. We discuss this issue is greater depth in section II.B.2.c.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter questioned the utility of the Payer-to-Payer API if payers other than impacted payers do not voluntarily adopt the technology and processes to share data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters supporting Payer to Payer adoption by payers other than impacted payers. We strongly encourage all payers not subject to these provisions to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may ultimately experience the benefits of such data exchange. Even though not every payer may participate in it, our Payer-to-Payer API policy can benefit the millions of Americans covered by impacted payers. We specifically encourage impacted payers that have other lines of business to adopt the policies in this final rule for their commercial plans that are not subject to the requirements of this rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS work with ONC and industry stakeholders to develop a longer-term FHIR roadmap, including patient-centric data homes that efficiently and effectively collect, storage, and integrate information from across the health system on behalf of a patient. Another commenter recommended that CMS work with the DoD and the VA to implement Payer-to-Payer APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for our Payer-to-Payer API policies and will continue to work with other Federal agencies to improve interoperability across the health care system.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters recommended delaying the Payer-to-Payer API compliance dates to give payers more time to design, develop, test and implement their systems. Some commenters recommended a January 1, 2027, compliance date, and another commenter recommended 4 years after the publication of the final rule, to give industry time to align on a standardized implementation approach. A few commenters suggested CMS delay compliance dates until IGs are mature enough to adopt as required standards, or to allow payers to adopt Payer-to-Payer API on a voluntary or pilot basis. Some commenters suggested CMS set rolling compliance dates and the Payer-to-Payer API should be prioritized after the Prior Authorization API. Several commenters specifically recommended that CMS to delay the compliance dates for state Medicaid agencies to implement a consistent solution at enrollment. A commenter requested that CMS accelerate the compliance dates to 2024. Another commenter urged CMS to consider the added cost and burden for payers to meet the proposed compliance dates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Because we understand that the payer implementation process is significant, after reviewing the comments, we are finalizing a modification to our proposal for the Payer-to-Payer API, to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). However, as discussed in 
                        <PRTPAGE P="8823"/>
                        section I.D.2., we decline to delay beyond that because of the importance of payer to payer data exchange. Establishing regulatory compliance dates will provide greater urgency to test and mature the evolving technical standards and IGs. When we proposed to require the relevant IGs in our December 2020 CMS Interoperability proposed rule, we received many comments that those standards were not mature enough to feasibly implement at that time. In response, we proposed in this rulemaking to only recommend (rather than require) the IGs for standardized implementation. After consideration of the comments we received in response to the CMS Interoperability and Prior Authorization proposed rule, we are finalizing those IGs as recommendations because it is prudent to move forward to attain the policy goals of the Payer-to-Payer API, even while those standards are being developed to achieve true interoperability. Moving to a 2027 compliance dates will give the industry an extra year to refine those IGs and for payers to implement their technical solutions.
                    </P>
                    <P>With regard to the requests for additional time for Medicaid programs specifically, we refer readers to section II.E.2.a. of this final rule where we finalize our proposals to create a process for Medicaid and CHIP FFS programs to request and be granted an extension to the compliance dates for the Payer-to-Payer API.</P>
                    <HD SOURCE="HD3">2. Proposal To Rescind the CMS Interoperability and Patient Access Final Rule Payer to Payer Data Exchange Policy</HD>
                    <P>We strongly believe that data exchange among payers is a powerful way to improve information sharing that would allow patients and providers to have more complete access to health information, which can help to promote better patient care. Patients may wish for their health information to follow with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information to better assist with continuity of that care. However, given the concerns raised by stakeholders regarding the lack of technical specification in our previously finalized policy, we proposed to rescind the payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We did so to prevent industry from developing multiple systems, and to help payers avoid the costs of developing non-standardized, non-API systems, and the challenges associated with those systems. We proposed a new policy that would, instead, require impacted payers to implement and maintain a Payer-to-Payer API using the FHIR standard. We stated that using FHIR APIs would ensure greater uniformity and ultimately lead to payers having more complete information available to share with patients and providers.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters supported CMS's proposal to rescind and replace the Payer-to-Payer API requirements finalized in the CMS Interoperability and Patient Access rule (85 FR 25568). They agreed that the proposals would help standardize data exchange and avoid developing duplicative systems. Multiple commenters strongly supported the newly proposed FHIR API approach and noted that this API would leverage the same standards as the Patient Access and Provider Access APIs. A commenter highlighted how CMS's proposal to replace the payer to payer data exchange addressed a key concern held by the industry about the lack of specificity in the previous policy. Another commenter stated that they welcomed the elimination of provider remittances and cost-sharing information from the required data content.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters support and are finalizing our rescission of the previous policy.
                    </P>
                    <P>We note that we are correcting a technical error in this final rule for the Payer-to-Payer API requirements in Medicaid managed care. When we proposed to remove the requirement at 42 CFR 438.62(b)(1)(vi) and (vii) and instead use a cross reference to 42 CFR 431.61(b)(1) at § 438.242(b)(7), we inadvertently neglected to properly revise 42 CFR 438.9 to continue excluding NEMT PAHPs from the Payer-to-Payer API requirements. When the payer to payer data exchange requirements were finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at § 438.62(b)(1)(vi) and (vii), NEMT PAHPs were automatically excluded as 42 CFR 438.62 is not applicable to NEMT PAHPs. However, by moving the Payer-to-Payer API requirements to § 438.242(b)(7), the requirements would apply to NEMT PAHPs (at 42 CFR 438.9(b)(7)). As we explained when we proposed to exclude NEMT PAHPs from the Provider Access API (87 FR 76258), we believed that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justified their exclusion from the requirements of the Provider Access API. Similarly, we do not believe that other payers have a routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Payer-to-Payer API would be an undue burden on them. It would also be a burden on other Medicaid payers concurrently covering a patient to receive NEMT data quarterly as required at 42 CFR 431.61(b)(5). To correct this oversight, we are finalizing 42 CFR 438.9(b)(7) to exclude the requirement at § 438.242(b)(7), which is to comply with § 431.61(a) and (b).</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter supported our proposal to rescind the previous requirements but urged us not to finalize our new Payer-to-Payer API proposals, because many of the technical standards are still undergoing development and refinement and operational processes have not been established by payers. The commenter suggested that CMS should consider establishing a voluntary payer to payer data exchange policy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that any new requirement is going to have operational challenges that need to be resolved. Technical standards have substantially developed over the past 3 years since we issued the December 2020 CMS Interoperability proposed rule (85 FR 82586). We refer readers to sections II.G.3.a. and II.G.3.b. of this rule for additional discussion on enhancements to both the required and recommended IGs published since the publication of the CMS Interoperability and Prior Authorization proposed rule. For example, the recently published PDex IG STU 2.0.0 specification now includes a Prior Authorization profile that enables payers to communicate prior authorization requests and decisions. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide additional time for stakeholders, and specifically payers, to address those barriers to implementation.
                    </P>
                    <HD SOURCE="HD3">3. Payer to Payer Data Exchange on FHIR</HD>
                    <HD SOURCE="HD3">a. Payer-to-Payer API Technical Standards</HD>
                    <P>In the CMS Interoperability and Patient Access final rule we finalized a requirement that impacted payers must implement, maintain, and use a Patient Access API conformant with 45 CFR 170.215. However, we did not require payers to use an API or specific standards for payer to payer data exchange in that final rule.</P>
                    <P>
                        In the CMS Interoperability and Prior Authorization proposed rule, we 
                        <PRTPAGE P="8824"/>
                        proposed an API-based payer to payer data exchange utilizing standards and technology similar to that of the Patient Access API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of the proposed rule) and the Provider Access API (discussed in section II.B.2. of the proposed rule) should ease the development and implementation of the Payer-to-Payer API for payers.
                    </P>
                    <P>The Patient Access API will provide the foundation to share adjudicated claims and encounter data, all data classes and data elements included in a standard adopted at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations. Because, as of January 1, 2021, the same adjudicated claims and encounter data, and all data classes and data elements included in the standard at 45 CFR 170.213 are already required for the Patient Access API, payers should have already formatted these categories of data and prepared their systems to share these standardized data via a FHIR API. As a result, payers have already devoted the development resources to stand up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for additional interoperability use cases.</P>
                    <P>We proposed that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must implement and maintain a Payer-to-Payer API that is conformant with the same technical standards, documentation requirements, and denial or discontinuation policies as the Patient Access API.</P>
                    <P>We proposed to require certain standards adopted under 45 CFR 170.215 that are applicable to the Payer-to-Payer API. We are finalizing our proposals for the Payer-to-Payer API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use SMART App Launch IG and OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Payer-to-Payer API.</P>
                    <P>One operational difference between the Patient Access and Payer-to-Payer APIs is that payers may find it more efficient to share data for multiple patients at a time. It is likely that impacted payers with a fixed enrollment period will have many patients' data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE). In such a situation, it could require significant time and resources for payers to send each patient's data individually through an API. The Bulk Data Access IG for exchanging multiple patients' data at once has been adopted by ONC at 45 CFR 170.215(d)(1), which is discussed further in section II.F. of this final rule and is a standard we proposed to require for the Payer-to-Payer API.</P>
                    <P>We requested comments on these proposals. We received multiple comments regarding technical implementation challenges and the maturity of the recommended IGs, which are addressed in section II.G. of this final rule. Here we respond to the comments specific to the standards and IGs for implementing the Payer-to-Payer API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated their support for the proposed FHIR standard and recommended IGs for the Payer-to-Payer API. Multiple commenters stated that the FHIR standard will ultimately prevent issues with data sharing across payers and allow information to be shared accurately and timely. Many commenters gave their support for our proposal that the Payer-to-Payer API must be conformant with the standards at 45 CFR 170.215, including support for the Bulk Data Access IG and OpenID Connect Core. Some commenters agreed with not requiring payers to use the CARIN IG for Blue Button or HL7 Da Vinci IGs. Additionally, other commenters explained that universally implementing FHIR would define how health care information is shared, but will have no impact on how data are collected or stored. Multiple commenters stated their support for requiring Payer-to-Payer APIs to use the same standards as the other interoperability APIs. A commenter stated that leveraging the same standards and IGs will support efficient implementation. Another commenter stated that the lack of standards has been one of the barriers to achieving data fluidity between payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support of the proposed standards and recommended IGs for the Payer-to-Payer API and agree that the using standards will support more efficient data sharing. Requiring impacted payers to use the same standards and IGs will support consistent implementation and improve interoperability across health care. We note that for the Payer-to-Payer API, we are finalizing a modification to our proposal by not requiring the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e)(1), as discussed further in section II.C.3.d.iii. of this final rule. Protocols requiring user level credentials managed by the payer, such as those used with OpenID Connect Core, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where a particular individual may not be directly initiating the exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters who supported the proposal that the Payer-to-Payer API must be conformant with FHIR at 45 CFR 170.215(a)(1) identified concerns with implementation. Multiple commenters agreed with the approach to require the FHIR standard for Payer-to-Payer APIs, but some commenters noted that the standard has not been widely demonstrated in production by industry stakeholders. A commenter stated that payers will need to create workflows to process exchanges, incorporate received data into local records, and troubleshoot any issues. A commenter recommended that CMS allow 1 to 2 years to implement new standards depending on complexity. The commenter encouraged data transfer standards be backward compatible.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that implementing new standards takes time and appreciate the commenter recommending we allow 1 to 2 years. However, technology and standards are ever evolving and will never remain static for the period it would take the entire industry to implement. To address comments about the time necessary for implementation, we are delaying the compliance dates for the Payer-to-Payer API to 2027, which will give implementers approximately 3 years from the publication of this final rule. Public comment has broadly indicated that the proposed standards will be sufficiently mature for implementation by that deadline. We will continue working with HL7, the FHIR accelerators, and industry stakeholders to define, to participate in and convene testing events, and to develop and maintain the specifications, which moves them towards greater 
                        <PRTPAGE P="8825"/>
                        maturity. Specifically, the PDex IG has been tested, implemented, and based on industry standard consensus, is ready for use. We acknowledge that the standards discussed in this rule will continue to mature to enhance functionality and meet additional use cases. We expect that future rulemaking by CMS and ONC will be necessary to keep pace with the latest technical innovations. While the technology may never be “done,” commenters indicated that the standards available today are sufficiently mature to facilitate 2027 compliance dates for the policies in this final rule that require API development or enhancement.
                    </P>
                    <P>We acknowledge that, as with any standard, potential compatibility issues could arise through the further development of those specifications. We discuss IG maturity further in section II.G.3.b. of this final rule. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, increasingly so with the level of adoption and use. As the IGs mature, the number of potential compatibility issues between versions is expected to decrease.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS name specific IG versions and standards as a baseline for the Payer-to-Payer API and create a formal standard version advancement process similar to the ONC Standards Version Advancement Process (SVAP). A commenter noted that an established SVAP would give the industry and HL7 the opportunity to continue refining and testing standards and IGs to ensure consistent implementation. A commenter recommended that CMS ensure that the applicable Payer-to-Payer API technical standards remain current as new versions become available. Multiple commenters specifically stated their concern for endpoint compatibility and recommended that CMS create required standards so that payers do not need to make one-off modifications to accommodate slightly different APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the proposed rule, we stated that we believed the approach of recommending, but not requiring, specific versions of the IGs would provide directional guidance without locking implementers into the versions of the recommended IGs available at the time of the proposed rule. To not recommend any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations have allowed the IG authors and community to receive feedback from real-world use and to further mature and refine the IGs. Certification and testing of these APIs could help avoid implementation variation and will consider ways for CMS to support such testing in the future. In addition, by using the recommended IGs, implementers can ensure that their APIs are compatible and conformant to the requirements. As the standards continue to mature, we will consider whether to propose requiring additional IGs through rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the proposed IGs are dependent on an outdated network authentication protocol and recommended using the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG, which leverages UDAP for authentication. Another commenter simply recommended utilizing UDAP for authentication. Another commenter recommended CMS modify the standards and IGs to adequately capture the Payer-to-Payer API requirements. The commenter stated that CMS should support the development of content and technical standards for prior authorization decisions that can be incorporated into the appropriate IGs for testing.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. As discussed in section II.C.3.d.iii. of this final rule, we are finalizing a modification to our proposal to not require the OpenID Connect Core and SMART App Launch IG standards for the Payer-to-Payer API. We recognize that methods such as SMART Backend Services (which is included in the SMART App Launch IG v2), mTLS, UDAP, or other trust community specified means may be appropriate depending on the needs. We refer readers to Table H3 in this final rule for an updated finalized list of all required and recommended IGs for the Payer-to-Payer API. We will continue to work with ONC to advance the versions of the standards that ONC adopts at 45 CFR 170.215. We will continue to monitor the development UDAP and other trust community specified solutions that could support the Payer-to-Payer API authentication process. We also note that ONC has adopted SMART Release 2.0.0 at 45 CFR 170.215(c)(2) and while we are not requiring the SMART App Launch IG for the Payer-to-Payer API, we do recommend using SMART Backend Services.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed support for maturing the PDex IG and noted that the IG still needs more testing for specific use cases. Another commenter suggested that CMS not finalize the Payer-to-Payer API until it works with HL7 to diminish the costs with the PDex IG. The commenter noted that in the PDex IG, the patient would be responsible for manually executing the data exchange using a third-party app and then transmitting that information to a new payer. Another commenter stated that the IGs identified for the payer to payer data exchange include the capability for two methods (member-mediated and member-directed), which would cause confusion and redundancy. The commenter stated that the member-directed solution would potentially give the new payer access to financial information meant to be available only to the patient.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The PDex IG provides multiple data exchange methods. One method allows a member to directly authorize data being sent to a third party. While this method could be utilized for payer to payer interactions, it is not the primary method defined by the PDex IG for that use case. For the Payer-to-Payer API use case, the PDex IG provides guidance for supporting exchanges that do not require direct member engagement. The PDex IG STU 2.0.0, which is being recommended for the Payer-to-Payer API in this rule, can facilitate on the payer to payer exchange by defining a means for the requesting payer to send a record of the patient's opt in to retrieve data from the other payer. This method does not require patient action through OAuth and is the method we recommend for payer to payer data exchanges. While we recognize that the PDex IG utilizes mTLS for payer authentication, we are not requiring that protocol and recognize that other methods, such as SMART Backend Services, UDAP, or other trust community specified means, may be appropriate and easier to implement at scale. Payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet the applicable security and privacy requirements.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters had concerns regarding FHIR due to the lack of mature HL7 FHIR IGs and recommended that CMS instead advance payer to payer data exchange by leveraging the TEFCA QHINs. A few commenters recommended that CMS address the need for a legal governance framework for payer to payer data exchange. A commenter recommended that CMS work with ONC and the TEFCA RCE to incorporate the payer to payer data exchange use case into TEFCA's planned support for payment and operations exchange. The 
                        <PRTPAGE P="8826"/>
                        commenter also recommended that CMS allow payers to comply with the Payer-to-Payer API requirements by participating in TEFCA.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenter that TEFCA can provide an efficient vehicle to query, send, and receive standardized electronic health information (EHI) from a broad array of participants enabling payer to payer data exchange. While standards and IGs for using FHIR within a network like TEFCA are still maturing, the FHIR Roadmap for TEFCA Exchange outlines the path for implementation. In addition, ONC and the RCE are currently developing the requirements in Common Agreement Version 2.0 for FHIR-based exchange under TEFCA across Exchange Purposes, including for Payment and Operations. ONC is aiming to publish Common Agreement Version 2.0 in the first quarter of 2024. To the extent that the requirements of this rule can be met through TEFCA exchange by the compliance dates, payers are permitted to do so. However, as there are methods for exchanging data under TEFCA that do not comply with the standards requirements we are finalizing (such as exchanging information using a method other than a FHIR API), participation in TEFCA, including exchanging the required data, does not necessarily mean that the payer is meeting the requirements of this rule.
                    </P>
                    <P>We note that payer to payer data exchange is legally required under this final rule and as such, legal agreements are not required. However, we understand that some payers may still request legal agreements. CMS is also working closely with ONC to explore how TEFCA could potentially be leveraged to support scalable governance for payer to payer exchange.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS requiring the Bulk Data Access IG. A commenter stated that this IG was designed to exchange population level data to allow payers and providers to analyze care using the tools of “big data” analytics and for bulk information exchange between payers and providers for populations covered under value-based arrangements. A commenter stated it is critical to pace mandates with the development and adoption of standards and that the Bulk Data Access IG is not finalized or adopted by HHS. Another commenter stated that while the Bulk Data Access IG is the correct specification for transferring large amounts of data between two payers, the IG is still evolving. A commenter highlighted that the Bulk Data Access IG will require additional development efforts for their organizations since it is new. Another commenter stated that the Bulk Data Access IG does not include aspects that are relevant to the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the ONC Cures Act final rule HHS adopted the Bulk Data Access IG at 45 CFR 170.215(d)(1). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the standards at 45 CFR 170.215, which includes the Bulk Data Access IG. In this final rule, we are finalizing standards applicable for each API. Bulk data exchanges are usually used for system-to-system use cases and allow large volumes of information on a group of individuals to be shared in one exchange, which could be useful for sharing data between payers. Therefore, we feel that the Bulk Data Access IG is relevant for the Payer-to-Payer API and is being finalized as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended blockchain based technologies be used for the payer to payer data exchange. A commenter recommended that CMS support and evaluate blockchain-based technologies for the payer to payer data exchange and recommended that there needs to be confidence in the ability of blockchain-based technologies to leverage APIs for associated data movement. Another commenter recommended that CMS retain regulatory flexibility to enable future data exchange opportunities, including the potential for permissioned on-chain PHI access rather than an API call and response model.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that there are a range of technologies that may facilitate interoperability. In conjunction with ONC, we are working to establish standards that result from the work of SDOs and have been generally agreed upon by the industry through consensus-based processes. Blockchain technologies do not meet those criteria at this time, but we will continue to monitor evolving technologies and their possible benefits for interoperability. In the meantime, we are not prohibiting payers from using blockchain technology if they are doing so in a way that meets their legal requirements.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters stated that payers, especially state Medicaid and CHIP agencies, would need technical assistance with implementing the Payer-to-Payer API. Multiple commenters stated that payers could use HIEs to implement the Payer-to-Payer API requirements, including the opt in process, which would reduce the burden on payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         CMS has hosted, and intends to host in the future, CMS and HL7 FHIR Connectathons, which are free for stakeholders to attend, as well as provide educational webinars providing overviews of the technical requirements set forth in the interoperability rules. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources and HL7 FHIR workgroup meetings. We understand that some payers may have implementation challenges and one of the reasons we are finalizing 2027 compliance dates is to give impacted payers additional time to prepare and test any new processes they may need to implement.
                    </P>
                    <P>To the extent that it reduces burden, we encourage payers to partner with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange, subject any other applicable laws governing privacy and disclosure of these data. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that existing payer systems do not. Nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. For instance, as HIEs may have access to clinical data from providers that payers do not, some impacted payers may want to contract with an HIE to host their required API, either as their repository for clinical data, or as an intermediary with the payer's own systems. The HIE could then augment payer data with other clinical data they have access to in order to enhance the data available to via the Patient Access, Provider Access, and Payer-to-Payer APIs, subject to other applicable law.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter cautioned that CMS's proposals could result in each payer building their own API, and each payer pulling data from every other payer within a state. A commenter stated that it is not feasible for every clearinghouse to maintain so many non-standard connections, and to do so would be costly and risky. The commenter stressed the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Impacted payers will not have to maintain non-standard connections for this payer to payer data exchange, as we are requiring impacted payers to use a FHIR API to support interoperable implementations. We are requiring impacted payers to use the same standards specifically so that connections between payers do not need to be “hard coded” but can rely on the 
                        <PRTPAGE P="8827"/>
                        same technical standards to connect to any other payer's endpoint. There is no requirement to use a clearinghouse, but to the extent it could benefit payers, we encourage them to leverage HIEs or HINs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS resolve the technological infrastructure dependencies by further investing in the HL7 FAST Accelerator and ONC's work to facilitate patient matching and support implementation of the HL7 FAST Accelerator solutions to enable scaled exchange through FHIR APIs. Another commenter recommended that CMS collaborate with ONC to encourage industry adoption of the solutions outlined by the HL7 FAST Accelerator, at minimum, identity resolution, security, and directory for the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We will continue to work closely with ONC on the FAST Accelerator and will seek to leverage any appropriate solutions being developed as part of this work. We are also committed to continuing to work with HL7, the Accelerators, and interested parties within the industry in defining, participating in, and convening testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity and will adopt solutions as appropriate to our use cases as they mature.
                    </P>
                    <HD SOURCE="HD3">b. Payer-to-Payer API Data Content Requirements</HD>
                    <HD SOURCE="HD3">i. Data Content</HD>
                    <P>We proposed to require impacted payers to implement and maintain a Payer-to-Payer API to exchange claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. As stated in the proposed rule (87 FR 76255), this set of data is consistent with requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 2555) and our proposals for the Patient Access and Provider Access APIs. Using the same data content standards across the APIs in this final rule adds efficiencies for payers and maximizes the value of the work that has already been done, reducing the overall burden for impacted payers.</P>
                    <P>In response to comments, we are finalizing our proposal, with modifications. We are modifying the data content by excluding data related to denied prior authorizations. In addition, we are also finalizing a modification by only requiring impacted payers to exchange data with a date of service within 5 years of the request.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed that using the same January 1, 2016, start date for the set of data that must be exchanged via the Payer-to-Payer API would include significant historical data that are unlikely to be relevant to a patient's current health status and ongoing care. Those commenters urged us to establish a rolling period of time to the date of the exchange for the data content that must be shared. Some commenters pointed out that the technical and operational level of effort to integrate a patient's full history would impose significant data storage and archival costs on payers. Some commenters disagreed with CMS's justification for the proposal that payers were the appropriate maintainer of a patient's complete health history and suggested that while payers had a role to play, patient apps could be a more efficient, effective and reliable method to meet that objective.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we continue to support and emphasize the benefits of payer to payer data exchange, we also recognize the burden of exchanging and storing large amounts of complex patient data. There are two main benefits for Payer-to-Payer API data exchange: to facilitate care continuity when a patient changes payers and to maintain the patient's record so that relevant information is not lost. After consideration of the comments, we agree that requiring impacted payers to exchange a patient's entire history back to the proposed January 1, 2016, date would impose a significant burden on payers to integrate and maintain those data. In effort to balance the benefits we described in the proposed rule, which were supported by commenters, and the burden that some commenters raised, we are finalizing a modification to our proposal to limit the payer to payer data exchange to only the previous 5 years of data.
                    </P>
                    <P>
                        As described previously, solutions are emerging in the marketplace for Personal Health Records (PHR) that are better suited to keeping patient records for an indefinite period than payers, which might themselves maintain limited clinical data. ONC defines a PHR as an electronic application through which patients can maintain and manage their health information (and that of others for whom they are authorized) in a private, secure, and confidential environment.
                        <SU>78</SU>
                        <FTREF/>
                         For instance, health apps can create a longitudinal record by gathering data both from payers via the Patient Access API, and providers' CEHRT. Even so, it is still important for patient care and continuity for a patient's new payer to receive and maintain some recent historical record of the patient's care. When a patient changes payers, only the information that the current payer maintains would be available via the Patient Access, Provider Access and Payer-to-Payer APIs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             Office of the National Coordinator for Health Information Technology (2016, May 2). Frequently Asked Questions. Retrieved from 
                            <E T="03">https://www.healthit.gov/faq/what-personal-health-record.</E>
                        </P>
                    </FTNT>
                    <P>As payers and providers will have a more robust infrastructure for data exchange (including via the FHIR APIs required in this final rule), they are better suited to enable data exchange to providers and between payers than a patient would be with their PHR. A patient could supplement information that their payer maintains with information from their PHR, but should not have the primary responsibility for ensuring the technical capability to send their records.</P>
                    <P>For continuity of ongoing care, we expect that the more recent data are, the more relevant they generally would be. Therefore, it is important to establish a period of time that is reasonably likely to include information relevant to foreseeable care after a patient changes payers. While many commenters suggested shortening the timeframe for data to be exchanged, we did not receive comments suggesting a specific period. Five years balances the needs to manage care continuity and establish a patient record with their new payer while not being overly burdensome on payers to exchange and maintain a large amount of data that may not be relevant. Being able to keep the most recent 5 years of data when transitioning between payers will cover the vast majority of a patient's ongoing and future healthcare needs. Even for patients with chronic conditions, data older than 5 years are unlikely to have significant relevance or value when more recent information is available. This amount of data sharing strikes the right balance of limiting the burden to payers, while still reaping the benefits of care coordination and continuity and allowing patients to maintain a significant amount of data with their current payer.</P>
                    <P>
                        However, we disagree with commenters who suggested limiting the data exchange to a shorter period to focus only on current health conditions and ongoing care. We do not want to 
                        <PRTPAGE P="8828"/>
                        narrow the scope of data to be exchanged to focus simply on care continuity. Health information that is not relevant at the time a patient changes payers may later be important for the patient or their providers to have access to. Beyond the care continuity justification for payer to payer data exchange, making a reasonable amount of patient data available, even if it is not the patient's full record, is still an important goal of this policy. For these reasons, and to better balance the burden on payers and benefit to patients, we are finalizing a modification to our proposal to only require the most recent 5 years of data be exchanged between impacted payers. We will monitor the Payer-to-Payer API implementation and usage to determine whether to extend this timeframe in the future.
                    </P>
                    <P>
                        For some patients, those 5 years of data may still comprise a significant quantity. However, the data content requirements for the Payer-to-Payer API are built on structured data standards, such as the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), which should be easily ingested using the recommended IGs. The exception to that structured data is administrative and clinical documentation submitted by providers related to prior authorization requests and decisions, as discussed later in this section of this final rule. We encourage impacted payers to review the PDex IG for guidance on ingesting patient data in a structured manner that creates a useable patient record.
                        <SU>79</SU>
                        <FTREF/>
                         We also note that CMS will continue to work closely with ONC and other Federal agencies to improve data interoperability through initiatives such as the USCDI+.
                    </P>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             Health Level Seven International (2023, October 28). Da Vinci Payer Data Exchange. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/davinci-epdx/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended narrowing the scope of data that would be exchanged via the Payer-to-Payer API. Some commenters suggested that CMS narrow the scope of information required to be exchanged to specific data that would facilitate a change in coverage. Other commenters recommended that CMS only require a minimum set of information necessary to facilitate a patient's transition and improve care coordination. Some commenters recommended that CMS work with industry stakeholders to determine a subset of key coverage, clinical, demographic, claims, and encounter information to share via the payer to payer data exchange to support coverage transitions. Another commenter expressed that the data exchange should be limited to claims data and prior authorization decisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree with the view that the information sent via a Payer-to-Payer API should be limited to a minimum set of data that would facilitate transition between payers and continuity of ongoing care. While care continuity is one purpose of the Payer-to-Payer API, there are use cases that benefit from additional information being sent. Specifically, we proposed to include claims, encounter data and clinical data to maintain the availability of those data for the Patient Access and Provider Access APIs after a patient changes payers. We acknowledge that a patient's historical data may not be directly relevant to a patient's care at the time of transition. However, that does not mean that a patient or provider would never have a reason to access those data. While the payer to payer data exchange has its use cases, the Patient Access and Provider Access APIs have additional use cases. Therefore, it is important to consider not just how a payer would use data received from a previous payer, but how patients and providers may use it as well. A patient should not lose access to their recent claims, encounter, or clinical data from their payer because they are not strictly necessary to facilitate the transition to a new payer. As discussed, we are finalizing a modification to our proposal to limit the data to be sent to that with a date of service within 5 years of the request.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters provided recommendations regarding clinical data to be exchanged. Some commenters stated that clinical information is not stored in a sharable format for the Payer-to-Payer API. Specifically, a commenter discussed how current technology cannot adequately parse through large, non-standardized files. The commenter noted that clinical information sent by providers to payers is not received, structured, or stored in a way to be shared, as the X12 275 transaction standard for healthcare claims attachments has not been finalized (though a standard has been proposed in the HIPAA Standards for Healthcare Attachments proposed rule (87 FR 78438)). In addition, a commenter recommended that CMS work with ONC to implement a requirement that providers share comprehensive clinical data in a FHIR enabled format with patients and payers. Another commenter recommended that CMS remove the requirement that impacted payers share all clinical information in USCDI and focus on the clinical information that has been received in standard, electronic structured format related to prior authorization. A commenter asked CMS to explain whether impacted payers only need to make available via the API the USCDI data classes and data elements that they currently maintain.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that not all information that we are requiring to be made available through the Payer-to-Payer API will be stored and maintained in a structured data format within the payers' systems. However, the benefits of ensuring that a patient's data follow them to a subsequent payer outweigh the burden of exchanging that information. In many circumstances, clinical information can be significantly more informative than claims or encounter information. For example, claims for laboratory tests will not provide the actual results of those laboratory tests, which is more important than simply knowing that laboratory tests were done without knowing what the results were. However, we know that many payers do not maintain clinical data, or only maintain specific sets of clinical data and therefore claims and encounter information can fill gaps that would otherwise be missing.
                    </P>
                    <P>Our data content requirements for the Payer-to-Payer API are built on the existing requirements for the Patient Access API. The set of clinical information that we have required to be available via the Patient Access API since January 1, 2021, is defined by the USCDI standard at 45 CFR 170.213. As discussed in section II.A.2.d. of this final rule, for clarity we are changing the regulatory text to point directly to the USCDI standard at 45 CFR 170.213 for the Patient Access API, as well as the new Provider Access and Payer-to-Payer APIs. Therefore, to the extent a payer maintains those data, the data classes and data elements in USCDI should already be in payers' systems in a form that makes them available via a FHIR API. Because payers should already have experience making that set of information available, there should not be a significant burden to make the same underlying data available through multiple APIs. Henceforth, with our revisions to directly reference the content standard at 45 CFR 170.213, the Patient Access, Provider Access, and Payer-to-Payer APIs will all be required to include all data classes and data elements within that content standard that are maintained by the payer.</P>
                    <P>
                        We are not adding any requirements in this final rule that would require payers to parse and convert 
                        <PRTPAGE P="8829"/>
                        unstructured files into structured data, either for their own records or to share via the APIs. We also expect that as standards are adopted across the industry, an increasing percentage of clinical data will be stored and transmitted in structured formats, which is a result we encourage. We note, however, that unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request (excluding those for drugs and those that were denied) are required to be sent through the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that the patient's choice whether to opt into the Payer-to-Payer API be part of the data exchanged.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         That piece of information is required as part of the attestation of patient opt in and is discussed in more detail in section II.C.3.d.iv. of this final rule. If a patient does not opt in, there would be no payer to payer data exchange under these requirements.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS reduce the quantity of data that needs to be exchanged by not requiring that denied claims be exchanged between payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While some denied claims may be extraneous (such as a claim denied because it is a duplicate), they may contain important information about a patient that would be beneficial to their record. A claim, even if it is denied, can indicate that a patient received items or services, even if the claim was not paid. Denied claims are also included in the information that is currently required to be available via the Patient Access API (85 FR 25532). We did not propose, nor are we finalizing, to exclude denied claims from the Payer-to-Payer API (or the Provider Access API). However, as discussed in section II.C.3.b.iii., we are excluding denied prior authorization requests from the set of information that must be exchanged between payers. Unlike claims, a denied prior authorization request does not indicate that the patient actually received items or services and therefore an exclusion is justified, as discussed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that payers have already formatted the necessary data elements and prepared their systems to share the standardized data through other FHIR APIs. A commenter noted that this infrastructure can be adapted for expanded interoperability use cases, such as the Payer-to-Payer API. However, another commenter believed that barriers to implementing FHIR APIs exist in the way of process siloes in payer organizations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the confirmation that payers have already formatted the necessary data elements to be shared through other FHIR APIs, particularly the Patient Access API. We agree that infrastructure can be adapted for this Payer-to-Payer API and are requiring the same data classes and data elements already required for the Patient Access API. Payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. We note that the Payer-to-Payer API data content requirement also includes both structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations, of which the unstructured documentation is not required to be shared through the Patient Access and Provider Access APIs. We also agree that payers have already devoted the development resources to standing up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for expanded interoperability use cases. Using the recommended IGs will reduce implementation barriers and we encourage payers to get involved in the HL7 FHIR workgroups and to collaborate with other payer organizations on these API implementations. In addition, we are delaying the compliance dates to 2027 rather than the proposed 2026 not just to give payers time to implement the technical requirements, but also to address any internal business process changes that may be necessary.
                    </P>
                    <HD SOURCE="HD3">ii. Provider Remittances and Patient Cost-Sharing</HD>
                    <P>We proposed to exclude provider remittances and patient cost-sharing information from the Payer-to-Payer API because that information is often considered proprietary by payers. While there could be value to patients having provider remittances and patient cost-sharing information available via the Patient Access API, exchanging those data between payers would have only a limited beneficial impact on care. We believed that information about provider remittances and patient cost-sharing under another payer would have no impact on a payer's ability to ensure care continuity when a patient changes payers. Furthermore, there are existing processes for coordinating payment when a patient has concurrent payers that we did not wish to affect. Sharing claims and encounter information, even without these cost details, would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), by providing more information about the patient's care history to support care coordination and efficient operation.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the exclusion of provider remittances and patient cost-sharing information from the data shared through the payer to payer data exchange. However, a few commenters noted that this policy could create additional development work if payers need to segment data elements to make provider remittances and patient cost-sharing information available via the Patient Access API, but not the Payer-to-Payer API (or Provider Access API).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that segmenting data could create additional burden for payers. However, as discussed in the proposed rule, we proposed to not require provider remittances and patient cost-sharing information be included in the data shared via the Payer-to-Payer API because payers may consider that information proprietary. We agree that cost information would have limited benefits to care continuity when a patient changes payers. However, as our policy to exclude that information is intended to protect the payer's proprietary information, we are not prohibiting payers from sending it. Therefore, if a payer believes that implementing their Payer-to-Payer API in such a way that includes provider remittances and patient cost-sharing information would reduce burden, they are not prohibited from doing so.
                    </P>
                    <HD SOURCE="HD3">iii. Prior Authorization Data</HD>
                    <P>
                        We refer readers to section II.A.2.a. of this final rule where we discuss in more detail how prior authorization data must be available through the Patient Access API—and therefore through the other APIs as well. Our proposals to include prior authorization data in the Payer-to-Payer API mirrored our proposals to include prior authorization data in the Patient Access and Provider Access APIs. We stated that it would be valuable for payers to make certain information about prior authorizations available via the Payer-to-Payer API, particularly when a patient enrolls with a new payer. Prior authorization data can inform a payer about ongoing treatments. Payers can use that information to determine whether a new patient needs a new prior authorization, and, if so, whether the information from the previous payer is sufficient for them to issue a decision without additional work by the patient or provider. Prior authorization is a significant focus of this final rule as a whole, and information about these requests and decisions could be beneficial to 
                        <PRTPAGE P="8830"/>
                        patients, providers, and payers. As discussed in more detail in section I.D., this final rule does not apply to any prior authorization processes or standards related to any drugs.
                    </P>
                    <P>We discuss prior authorization and prior authorization processes in more depth in section II.D. of this final rule. We proposed to add certain information about prior authorizations to the set of data that impacted payers must make available via the Payer-to-Payer API upon request from another payer. We proposed that the information must include:</P>
                    <P>• The status of the prior authorization;</P>
                    <P>• The date the prior authorization was approved;</P>
                    <P>• The date or circumstance under which the authorization ends;</P>
                    <P>• The items and services approved;</P>
                    <P>• The quantity used to date; and</P>
                    <P>• Related administrative and clinical documentation.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters generally supported including prior authorization information in the Payer-to-Payer API and stated that this would increase transparency, improve care coordination, and reduce burden on providers, patients, and payers. Commenters stated that including prior authorization data in the Payer-to-Payer API would protect beneficiaries' access to necessary items and services since information on prior authorization is not always transferred when beneficiaries switch coverage today. A commenter stated that prior authorization information would enable the new payer to provide continuous coverage for existing treatments and highlighted that this is especially important for patients receiving cancer treatment and specific medications after progressing through step therapies. Multiple commenters expressed support for sharing historical data to increase payer knowledge of previous patient prior authorization decisions and health care data, and to encourage continuity of care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters concurring on the importance of previous payers sharing authorization data. The prior authorization process is a priority area for us to reduce patient and provider burden.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that some types of prior authorization data should be excluded from the Payer-to-Payer API. A few commenters suggested that CMS not require impacted payers to include information about prior authorizations without fully understanding how payers could use that information. Commenters specifically recommended that CMS exclude information about previously denied prior authorizations. A commenter noted that this might be used to limit care for patients, even if they meet the new payer's criteria for the same service. Conversely, another commenter noted that there is some benefit to patients and providers having a basic history of denied prior authorization requests.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After considering the comments we received, we are removing the requirement to include denied prior authorization decisions in the Payer-to-Payer API. However, we note that supporting clinical information associated with such decision may be available under the requirement to share all data classes and data elements included in the data content standard at 45 CFR 170.213 (USCDI) that are maintained by the payer. As discussed previously, we are focusing on the aspects of payer to payer data exchange that relate to care continuity when a patient changes payers. Because a previously denied prior authorization decision generally would not reflect ongoing treatment, and thus the information may not support care continuity, the value of including such information would likely be outweighed by the drawbacks of doing so. A denied prior authorization decision does not provide information about the patient's ongoing care because it does not show that patients received any items or services. If a patient did receive those items or services despite the denial of coverage, that information would have to be gathered from elsewhere (such as clinical data), regardless of whether the payer receives information about the denied prior authorization decision. However, we emphasize that denied prior authorization decisions are required to be shared via the Patient Access and Provider Access APIs because the benefits to those parties of accessing that information can be significant, especially for resubmitting requests or appealing decisions.
                    </P>
                    <P>However, this information could be used in ways that would negatively impact a patient's care or coverage. For example, information about a denied prior authorization decision could potentially create bias in future prior authorization decisions with the new payer, and patients could experience challenges to obtain coverage for a given service. Even if a previously denied prior authorization does not in fact create bias with the new payer, some patients may fear that result, which could lead to fewer patients opting in to payer to payer data exchange.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters recommended not including the quantity of services used to date due to the concern that health plan claims data updates are often delayed and, therefore, may not be a reliable source to track the number of authorized services used to date. A commenter recommended that CMS require only the authorized units of items and services for a specific prior authorization, rather than the items and services used under the authorization.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Upon reviewing comments, we agree with the many commenters who pointed out that the authorized services used to date under a prior authorization may be more confusing than useful for patients and providers. We heard that the quantity used to date would only be available based on claims that have been submitted and adjudicated for those items or services. Because there can be a significant lag between the items or services being provided and the claim being adjudicated, the information available through the APIs could be out-of-date and inaccurate. Therefore, we are finalizing a modification to our proposal that will not require payers to share the number of items or services used under the authorization. We are also finalizing a modification to our proposals that this information does not need to be included in the Patient Access API (discussed in section II.A.2.a.ii. of this final rule) or the Provider Access API (discussed in section II.B.2.g. of this final rule).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters encouraged CMS to include unstructured documentation and forms that were submitted as part of a prior authorization request. Some payers commented that making that documentation available via the Payer-to-Payer API will facilitate their ability to make prior authorization decisions for a new patients without requesting duplicative information be submitted. Commenters stated that unlike in the Patient Access and Provider Access APIs, sharing supporting documentation through the Payer-to-Payer API could allow the new payer to use that information to make decisions about subsequent prior authorizations, if required. A few commenters held the opposing view that CMS should not finalize requirements to include clinical documentation and forms with prior authorization information via the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are finalizing a modification to our proposal for the Patient Access and Provider Access APIs to remove the proposed requirement to make available unstructured administrative and clinical documentation. We have concluded that 
                        <PRTPAGE P="8831"/>
                        for these APIs, the burden outweighs the benefit. However, that is not the case for the Payer-to-Payer API. One of the goals of this regulation and the Payer-to-Payer API requirement is to promote greater continuity of care when patients change payers, especially regarding prior authorization. In order for payers to ease that transition, they need as much relevant data related to recent and ongoing care as possible. For instance, current data can allow a payer to authorize coverage for ongoing treatment, without requiring repeat testing or needing a provider to resubmit clinical information that the provider has already submitted to a previous payer.
                    </P>
                    <P>In addition, the concerns regarding payers' ability to quickly make the unstructured administrative and clinical documentation available, via the Patient Access and Provider Access APIs, do not apply to the Payer-to-Payer API. Under our Patient Access and Provider Access API policies, payers have 1 business day from the time they receive the prior authorization request or there is another status update to make prior authorization information available. For the Payer-to-Payer API, absent a specific patient request, typically payers only have to exchange data at the time a patient changes payers, or quarterly for concurrent payers. Therefore, unless a prior authorization request is submitted within the last days of coverage, payers will have a longer timeframe to ensure that unstructured documentation is included in the patient's record and can be transferred to another payer when the need or requirement to transfer data through the Payer-to-Payer API arises. Furthermore, the concern about a patient app or provider's EHR not being able to read and display unstructured documentation does not apply to payers, which regularly receive unstructured administrative and clinical documentation with prior authorization requests.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that given the complexity and variation across prior authorizations, any pertinent data from peer-to-peer reviews should be included in Payer-to-Payer API exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Based on comments and conversations with payers, we understand that many payers consider the specific criteria they use to make prior authorization decisions to be proprietary information. In addition, because payers have different criteria, information about internal peer reviews of prior authorization requests from another payer has only limited usefulness. Therefore, we are not requiring payers to exchange any documentation that the payer itself generates regarding a peer-to-peer review of a prior authorization request. But we are requiring impacted payers exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations to assist care continuity and allow payers to make their own decisions based on the patient's specific needs without requiring duplicative submissions from a provider.
                    </P>
                    <HD SOURCE="HD3">iv. Duration of Prior Authorization Data to be Exchanged</HD>
                    <P>We proposed that impacted payers would be required to make certain information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and for at least 1 year after the prior authorization's last status change. We proposed to require the availability of prior authorization information for at least 1 year after any status change across the Patient Access, Provider Access and Payer-to-Payer APIs, so that information from denied and expired prior authorizations would not be lost when they were not approved or no longer active.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported CMS's proposal that certain information about prior authorizations be available for the duration of an active authorization and for at least 1 year after the last status change. Some commenters were in favor of retaining a patient's historical prior authorization data indefinitely. Another commenter requested clarification on how the proposal to make prior authorization data available for at least 1 year would align with the requirement that impacted payers make available patient data with a date of service on or after January 1, 2016.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed previously, we are finalizing a modification to our proposal that will not require denied prior authorization requests to be shared via the Payer-to-Payer API at all. Such information must be shared through the Patient Access and Provider Access APIs beginning in 2027 (see sections II.A.2.ii. and II.B.2.g. of this final rule for more information). We note that the requirement to share patient data with a data of service on or after January 1, 2016, comes from the CMS Interoperability and Patient Access final rule, which required claims, encounter information and certain clinical data to be made available via the Patient Access API. Prior authorization information was not included in that rule, and therefore, we do not have reason to believe that payers are generally maintaining prior authorization data back to that date. In addition, the obligation to share encounter, claims, or other information from within 5 years of the request is contingent on the payer maintaining those data; for payers that are not required to maintain records past a certain point or that do not have internal policies for retaining records past a certain time period, the data may not be available to be shared through the Patient Access API. As discussed in the proposed rule, the availability of claims and clinical data are more important to patient care than information about prior authorizations that have expired. Claims and encounter data indicate items and services that the patient actually received in the course of their care. Information from a prior authorization indicates whether certain items and services were approved for coverage, and often the basis for that decision. While active or recent prior authorization information is important because it can indicate current or recent medical necessity, such information cannot be inferred from prior authorizations that have been expired for more than 1 year as they would not indicate any sort of ongoing care. Claims and clinical data maintained by the previous payer that are related to the treatment that occurred under an expired prior authorization would replace the need for the expired prior authorization decision itself. While claims and clinical data associated with an expired prior authorization can indicate the type of care received, as discussed earlier in this section, the value to a new payer of prior authorizations that were not acted upon, meaning they do not have a claim or any clinical data associated with them and are not associated with any past treatment or active care for the patient, is outweighed by the potential drawbacks of including such information. We also considered comments summarized previously and also discussed in sections II.A. and II.B. of this final rule regarding the inclusion of these data in the Patient Access and Provider Access APIs. While some API content differences may be beneficial or practical (such as the exclusion of provider remittances and patient cost-sharing information), we are keeping the API requirements as similar as possible to reduce burden by standardizing data content. We emphasize that for ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than 1 year. Furthermore, our policy allows payers to make these prior authorization data available for longer 
                        <PRTPAGE P="8832"/>
                        than 1 year, if they believe it adds value to patients, providers, themselves or future payers.
                    </P>
                    <HD SOURCE="HD3">v. Considering Prior Authorizations From Another Payer</HD>
                    <P>While we did not propose to require payers to review, consider, or honor the active prior authorization decision of a patient's former payer, payers may gain efficiencies by doing so. We sought comment on the benefits, burdens and considerations of imposing such a requirement. However, we did not make any proposals and therefore are not finalizing any policies in this area. We do note that since we published the proposed rule, the Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly final rule (CY 2024 MA and Part D final rule) was issued, which requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization, during which the new MA organization may not require prior authorization for an active course of treatment.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested clarification about the relationship between this final rule and the provision for MA plans at 42 CFR 422.112(b)(8)(i)(B) added by the CY 2024 MA and Part D final rule. That rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization during which the new MA organization may not require prior authorization for an active course of treatment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The requirements at 42 CFR 422.112(b)(8) adopted in that recent final rule apply to Part A and B benefits covered by an MA plan. An “active course of treatment” is defined at 42 CFR 422.112(b)(8)(ii) as a course of treatment in which a patient is actively seeing a provider and following a “course of treatment,” which is defined as a prescribed order or ordered course of treatment for a specific individual with a specific condition, outlined and decided upon ahead of time with the patient and provider. A patient can have an active course of treatment to which 42 CFR 422.112(b)(8) will apply that did not require prior authorization by their previous payer.
                    </P>
                    <P>Per 42 CFR 422.112(b)(8)(i)(B), MA organizations offering coordinated care plans must have, as part of their arrangements with contracted providers, policies for using prior authorization that provide for a minimum 90-day transition period for any active course(s) of treatment when an enrollee has enrolled in an MA coordinated care plan, even if the course of treatment was for a service that commenced with an out-of-network provider. Further, the MA plan cannot deny coverage of such active courses of treatment on the basis that the active course of treatment did not receive prior authorization (or was furnished by an out-of-network provider) but may review the services furnished against the MA plan's coverage criteria when determining payment. This includes enrollees who are new to an MA plan, an enrollee switching from Traditional Medicare to MA, or enrollees new to Medicare and enrolling in an MA plan for the first time.</P>
                    <P>In that final rule, we explained how we expect any active course of treatment to be documented in the enrollee's medical records so that the enrollee, provider, and MA plan can track an active course of treatment to avoid disputes over the scope of the new requirement. Therefore, an active course of treatment should be included in the data exchanged between impacted payers, regardless of whether a previous payer required a prior authorization. Under this final rule, the data content that must be shared via the Payer-to-Payer API includes the claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request. Almost any active course would be represented within that dataset. Any active course of treatment covered by 42 CFR 422.112(b)(8)(i)(B) will thereby become part of the patient's record with their new payer. It is important, especially in light of 42 CFR 422.112(b)(8), that MA enrollees are aware that their active course of treatment is being honored and for how long. That will allow MA enrollees in plans subject to this new requirement, and their providers, to plan for a new prior authorization request, if necessary.</P>
                    <P>Although this particular need for access to information about active courses of treatment is unique to MA enrollees in MA coordinated care plans, the data exchange and Payer-to-Payer API requirements outlined here are applicable to any impacted payer. While we encourage other payers to honor an active course of treatment similar to the requirements of 42 CFR 422.112(b)(8) for MA coordinated care plans, we have not proposed to require that of any payers not covered by that rule.</P>
                    <HD SOURCE="HD2">c. Identifying Previous and Concurrent Payers and Opt In</HD>
                    <HD SOURCE="HD3">i. Process Timing</HD>
                    <P>We proposed that all impacted payers develop and maintain processes to identify a patient's previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Additionally, we proposed that impacted payers would be required to establish similar processes for current patients prior to the compliance dates, to ensure those patients have the ability to opt in and have their data shared through the API. We are finalizing a modification to this proposal, as discussed, to establish a deadline for these processes at 1 week after the start of coverage (as that term is defined for each program).</P>
                    <P>We emphasized in the proposed rule that obtaining a patient's opt in permission and identifying the previous/concurrent payer(s) could not delay an applicant's eligibility determination or start of coverage with any impacted payer. We noted that the proposed requirement to identify a patient's previous/concurrent payer(s) and obtain a patient's opt in may not always be feasible before the start of coverage, for instance, if a patient does not provide enough information to identify their previous payer. We emphasized that payers must begin this process before the start of coverage, but realize that it may take longer than enrollment. In that case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous/concurrent payer(s). Only once the impacted payer has received permission and identified those other payers would they be required to request patient data, as outlined in sections II.C.3.c.ii. and II.C.3.c.iv. of this final rule. Using Medicaid as an example, if a state has all the information necessary to determine an individual's eligibility before it has identified the previous payer, the state must determine the individual's eligibility and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment.</P>
                    <P>
                        For new patients enrolling on or after the compliance dates, we proposed to require impacted payers to maintain a process for patients to opt into the Payer-to-Payer API data exchange and to 
                        <PRTPAGE P="8833"/>
                        identify their previous/concurrent payer(s) prior to the start of their coverage. In section II.C.4.b. of this final rule, we discuss the possible incorporation of these requirements into state applications for Medicaid or CHIP eligibility. In the proposed rule, we stated that making this process available to patients during the enrollment process, or immediately thereafter, would allow the proposed data exchange to take place as quickly as possible once the patient is enrolled with the new payer. For example, where there may not be communication during the enrollment process such as during the QHP enrollment on the FFEs, this process should be done immediately following enrollment. We solicited comment on incorporating the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265.
                    </P>
                    <P>Concurrent coverage means that an individual has coverage provided by two or more payers at the same time. This could include, for example, individuals dually eligible for Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan. Another example of concurrent coverage is when different services are covered by different Medicaid managed care plans for the same Medicaid beneficiary.</P>
                    <P>Several payer deadlines in this rule are based on a patient's “start of coverage.” For example, we proposed (and are finalizing) a requirement for impacted payers to request previous and concurrent payer information and a patient's opt in for Payer-to-Payer API data exchange (discussed in section II.C.3.c.iv. of this final rule) no later than 1 week after the start of coverage. Throughout the preamble, we are using the term “start of coverage” to mean when coverage begins or, if coverage begins retroactively, to refer to a later milestone, depending on the payer type. However, to ensure feasible timeframes for new patients after the compliance dates, we are finalizing deadlines based on whether coverage starts prospectively or retroactively. Where coverage starts prospectively, the deadline will be based on the coverage start date (also known as the coverage effective date). In the case of retroactive coverage, to avoid a deadline in the past, the deadline for the payer to provide the required information about the Payer-to-Payer API, request identifying information about previous/concurrent payer(s), and an opt in will be based on the date that the payer gets patient information and makes the patient's coverage effective.</P>
                    <P>Because the enrollment and coverage initiation processes for each program differ in their specifics, in regulation text, the concept of “start of coverage” is described differently for each type of impacted payer. That is, the regulatory text uses different, program-appropriate terminology for each impacted payer.</P>
                    <P>
                        For MA organizations, the “start of coverage” generally means the effective date of coverage, as used at 42 CFR 422.68. In some instances, an individual's enrollment may be accepted by CMS with a retroactive effective date of coverage, as discussed in the Medicare Managed Care Manual, Chapter 2, section 60.4.
                        <SU>80</SU>
                        <FTREF/>
                         In those cases, the “start of coverage” would be the date that the individual's enrollment is accepted by CMS.
                        <SU>81</SU>
                        <FTREF/>
                         Effectively, this means that the “start of coverage” is whichever is the later of those two dates—the effective date of coverage or the date that the individual's enrollment is accepted by CMS.
                    </P>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             Centers for Medicare and Medicaid Services (2011, August 19). Medicare Managed Care Manual. Retrieved from 
                            <E T="03">https://www.cms.gov/files/document/cy-2024-ma-enrollment-and-disenrollment-guidance.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             
                            <E T="03">See</E>
                             also Medicare Managed Care Manual, Chapter 2, section 40.4.2. for similar enrollee notification requirements tied to the date that the individual's enrollment is accepted by CMS.
                        </P>
                    </FTNT>
                    <P>For example, an MA organization that receives an enrollment request from an individual that is accepted by CMS in January for a February 1 effective date of coverage, would have 1 week from February 1 to complete the applicable requirements. An MA organization that receives an enrollment request from an individual in January that is accepted by CMS on February 7 for a retroactive February 1 effective date of coverage, would have 1 week from February 7 (not February 1) to complete the applicable requirements as finalized in this rule.</P>
                    <P>For Medicaid, a beneficiary's coverage is generally retroactive 3 months from the date that they are enrolled in Medicaid. For CHIP, retroactive coverage varies among states. Therefore, for Medicaid and CHIP FFS and managed care, the “start of coverage” is simply the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date coverage takes retroactive effect.</P>
                    <P>For QHP issuers on the FFEs, the start of coverage is generally the enrollee's QHP coverage start date. In some cases, a payer may provide coverage retroactively, that is, a payer provides coverage starting on a date prior to enrollment, for instance due to the birth, adoption, or foster care placement of a new child. In that case, the “start of coverage” would be the effectuation of coverage, as described at 45 CFR 155.400(e)(1)(iii). Effectively, this means the “start of coverage” is whichever is the later of those two dates—either the coverage start date or the effectuation of coverage. We refer to the coverage start date as the first date for which the enrollee has coverage and the term “effectuation of coverage” to refer to the date that the payer takes the steps to implement coverage, even if that coverage starts retroactively.</P>
                    <P>For example, an FFE QHP issuer that receives enrollee information during an annual open enrollment period for a consumer whose coverage will start on January 1 of the following year would have 1 week from the enrollee's coverage start date of January 1 to complete applicable requirements. An issuer that receives information and effectuates coverage on March 6 for an enrollee whose coverage starts retroactively on February 1 would have a week from the enrollee's effectuation date, March 6 (not February 1), to complete the applicable requirements.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding processes for opting in and collecting previous/concurrent payer data occurring at the start of coverage, noting logistical challenges to collecting data at the time of a patient's enrollment, including document format and regulatory challenges to updating existing enrollment forms. Multiple commenters provided recommendations regarding actions for payers to take at the time of enrollment to facilitate collecting this information, such as defining specific data and updating enrollment forms.
                    </P>
                    <P>
                        In addition, multiple commenters stated that payers should be permitted to collect a patient's opt in after enrollment. A commenter specifically recommended that collection should be allowed during the first month of active enrollment. Some commenters urged CMS to not require payers to collect data at enrollment to support the Payer-to-Payer API, and instead to allow outreach to patients after enrollment through existing tools, such as payer portals. Another commenter stated that requesting that information at the time of the patient's application would allow them to incorporate the process into their existing data collection processes. A commenter noted that the inability to opt in after the enrollment start date could result in low participation rates. Another commenter supported allowing patients to opt into data sharing during the open enrollment period. A commenter supported allowing a payer to collect a patient's opt in prior to the compliance dates for state Medicaid and CHIP agencies and prior to enrollment 
                        <PRTPAGE P="8834"/>
                        of new beneficiaries after the compliance dates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that the terms used in the preamble and regulation text of our proposed rule were different. Our discussions in the proposed rule referred to “prior to the start of coverage,” which we explained in preamble and fully discussed throughout the proposed rule, but the proposed regulation text used the phrase “at enrollment” (except for QHP issuers on the FFEs where we used “no later than the effectuation of enrollment”). We did not propose that new payers collect previous payer information at the time of enrollment. We stated that payers must begin the process of collecting the previous payer information and opt in prior to the start of coverage, but that it may take longer than the enrollment process. We are modifying the regulatory text to identify the start of coverage (rather than enrollment) as the milestone that tolls these requirements, consistent with the preamble discussion in the proposed rule.
                    </P>
                    <P>However, in response to public comments, we are finalizing a modification to our proposal by extending the deadline for both requesting identifying information about a patient's previous/concurrent payer(s) and seeking opt in from the patient to 1 week after the start of coverage, with certain differences among payers. For MA organizations, we are modifying the deadline to no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. In the case of Medicaid and CHIP FFS, we are modifying both deadlines to refer to 1 week after enrollment, to avoid confusion related to the retroactive eligibility rules in Medicaid. For QHP issuers on the FFEs, we are modifying the requirement to no later than 1 week after the after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. Commenters were clear that establishing the start of coverage as the deadline for these actions would result in logistical challenges and compliance would be difficult for impacted payers. We understand that while some types of impacted payers, such as MA organizations, may have contact with patients before the start of coverage, in other cases, payers do not. Furthermore, while we are recommending that state Medicaid and CHIP agencies incorporate these requirements into their applications for coverage, states would have few other options for communicating with patients before enrollment (which is how “start of coverage” is captured in the regulation text for Medicaid and CHIP).</P>
                    <P>We emphasize that payers must begin the process of collecting the previous/concurrent payer information and opt in no later than 1 week after the start of coverage but understand that it may not be completed within that timeframe. We believe it is important to gather this information from patients as soon as possible when a patient enrolls with a new payer in order to facilitate the timely exchange of patient data. Patients may take additional time to respond or follow-up may be required. Impacted payers are encouraged to make a reasonable effort to engage with patients to gather their permission and identify any previous/concurrent payer(s). We rely on payers to develop reasonable processes to follow up with patients, and recommend payers follow-up one time before determining that the patient is choosing not to opt in. Though not required, we encourage payers to build into their request process a method for patients to indicate that they do not want to provide the requested information, so that payers need not follow up with them. We note that the patient education requirements, discussed in section II.C.3.g. of this final rule, will provide patients annual reminders of the payer to payer exchange functionality. Under this final rule, patients must be able to opt in or withdraw permission at any time.</P>
                    <P>The opt in and identifying previous/concurrent payers processes could include using existing portals to gather this information from patients, as we are not being prescriptive on how each payer implements this process. We also encourage stakeholders to participate in HL7 FHIR workgroups to collaborate with other industry stakeholders on identifying best practices and identifying possible processes.</P>
                    <HD SOURCE="HD3">ii. Gathering Previous and Concurrent Payer Information</HD>
                    <P>We proposed that impacted payers would be required to gather information about patients' previous/concurrent payer(s) that would allow them to identify and request data from those payers. That could include the payer's name and a patient ID number or similar identifier. Under our proposal, an impacted payer would be required to allow a patient to report multiple previous/concurrent payers if they had (or continue to have) concurrent coverage. In this circumstance, we proposed that impacted payers would be required to request the patient's data from all previous/concurrent payers.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern with the lack of a standardized process to identify a patient's previous/concurrent payer(s) and recommended that CMS either establish a policy to identify the payers, provide technical assistance on how to crosswalk unique identifiers, or standardize elements of the process. A commenter highlighted that the lack of clarity on how payers are to identify a patient's previous/concurrent payer makes the Payer-to-Payer API difficult to operationalize and would likely introduce errors. Multiple commenters recommended additional changes to the enrollment process to support data exchange via the Payer-to-Payer API. A few commenters recommended that CMS work with stakeholders to develop a specific process to collect this information. A commenter urged CMS to reinforce to payers that they should make the processes as easy as possible for patients by leveraging touchpoints that the patient would already be engaged in to enroll and initiate new coverage.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Because the requirements for a Payer-to-Payer API and the need to collect information about previous or concurrent coverage for patients crosses many payer programs with variation between enrollment processes, we determined that being prescriptive on a specific process would cause more implementation burden than necessary. In response to comments, we are finalizing a modification to our proposal to require payers to request previous and concurrent payer information no later than 1 week after the start of coverage. As discussed previously, payers might not have contact with patients before enrollment. Therefore, this modification will allow additional time for payers and broaden the range of options for payers to align with their current processes. Initial implementation may be challenging; however, it is important that patients' data are shared as they transition care to a new payer, because the benefits for patients outweigh the upfront implementation burden. Leaving the process open for payers to implement in the least burdensome, most practical way to gather the information from patients makes the most sense. Gathering previous payer information and an opportunity for the patient to opt in ideally should take place through an already established point of contact with the patient. Leveraging established points of contact will reduce patient burden and help impacted payers meet the deadline of no later than 1 week after the start of coverage. In particular, payers often have existing processes to identify concurrent payers to facilitate 
                        <PRTPAGE P="8835"/>
                        coordination of coverage and Medicare Secondary Payer/Third Party Liability administration. For instance, per 42 CFR 422.108, MA organizations are required to identify payers that are primary to Medicare and coordinate its benefits to Medicare enrollees with those primary payers. State Medicaid programs are required to collect sufficient information to enable the state to pursue claims against such third parties when making an eligibility determination or redetermination per section 1902(a)(25) of the Act (for beneficiaries enrolled in managed care, states generally make this the responsibility of the MCO with state oversight). That requirement also applies to state CHIP programs by cross reference at section 2107(e)(1)(B) of the Act. Nothing in this rule would prevent payers from using that information for both that purpose and to identify concurrent payers for Payer-to-Payer API data exchange. However, patients would still need to opt in for payers to proceed with requesting patient data via the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters requested clarification on whether the definition of “previous payer” is limited to the immediately previous payer or to previous payers within a specific time period, such as within the last 5 years.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The minimum requirement is only to request information from the immediately previous payer, however if a patient does report multiple previous payers, impacted payers are required to request that patient's data from any previous/concurrent payers (identified to or known by the impacted payer) within the required 5-year period. We are finalizing that policy because patients may have been enrolled with payers that are not subject to the requirements of this rule. Therefore, allowing patients to have their impacted payers request data from payers other than their immediately previous payer within the 5-year timeframe could maintain as much of their record as possible.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS include a process for new payers to inquire whether the previous payer supported the Payer-to-Payer API described in this regulation, such as a monitored email address, and that some type of consequence for non-compliance should be levied.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers' digital endpoints and identify payers that support the Payer-to-Payer API. Without an NDH or similar source of information, payers would likely be required to contact the previous payer directly to determine if they support the Payer-to-Payer API. We are also exploring other solutions, such as using TEFCA, that could be leveraged to determine if the previous payer supports the Payer-to-Payer API. We have addressed program enforcement and compliance mechanisms in section I.D.2. of this final rule, as well, and appreciate public interest in mechanisms for provider and patient appeals and complaints, oversight, and assurance of compliance.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that a payer's ability to request data from a previous payer would be dependent on the patient providing accurate information about the previous payer. The commenter expressed concern regarding the accuracy of this information and the effort required for necessary follow-up.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed previously, we acknowledge that the obligation to exchange data is contingent on patients supplying the necessary information about previous/concurrent payers. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. We emphasize that payers must request this information no later than 1 week after the start of coverage, but that it may take longer than that to obtain information from the patient. If the patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to obtain their response to the opt in request and to identify any previous/concurrent payer(s).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested data elements that would be necessary or extraneous to make that Payer-to-Payer API request. Multiple commenters encouraged including the patient's name, patient's previous/concurrent payer name, member ID, date of birth, physical address, and phone number in a payer's data request to a previous payer. Multiple commenters urged payers not to require patients to provide the specific plan name, which may be long and unintuitive and because patients may have switched plans over time with that payer. A commenter expressed security concerns with exchanging Social Security numbers (SSNs) and suggested that their use be as limited as possible. Another commenter suggested that patients should be encouraged to provide the dates coverage started and ended or information about up to three recent services covered by the previous plan and those dates of service.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that demographic information such as patient's name, member ID, date of birth, physical address and phone number are appropriate pieces of information to identify patients. We also agree that SSNs should be used to identify patients only when necessary (and permissible by law) due to that identifier's sensitivity. While start and end dates of coverage may be useful in some instances, patients are unlikely to know or remember those exact dates, nor are they likely easy to find. Therefore, we discourage their use for identifying patients. Asking a patient to provide information about recent services covered by the previous payer could be burdensome to a patient. Patients are unlikely to have that information without gathering it from their previous payer. Therefore, there are less burdensome ways to effectuate this process, such as by using the data elements mentioned previously. Payers should implement these requirements in such a way that accomplishes the goal of identifying patients' previous/concurrent payer(s) with the least burden on patients.
                    </P>
                    <P>
                        The data elements that a payer may need to identify a patient and match that patient to their record are included in the required and recommended standards for the Payer-to-Payer API. Specifically, the required US Core IG and the recommended PDex IG have “Must Support” fields (meaning that the system must be able to support those data elements) that could be used for identifying a patient, such as patient name, addresses, birth sex, gender, birth date, member and subscriber identifiers, and group number. Requesting payers should use those fields to identify the patient whose data they are requesting. If the information provided is insufficient to make a match, or it matches with more than one member, an error should be returned. Payers will need to use a combination of data elements to support patient matching, as they do today with any data exchange. We also will continue to work with ONC and share information on their patient matching research/initiatives here: 
                        <E T="03">https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and-patient-record-matching.</E>
                         We encourage payers to leverage the appropriate patient matching data elements of the IGs and we will continue to work on ONC on their patient matching research and initiatives.
                        <SU>82</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             Office of the National Coordinator for Health Information Technology (2022, September 8). Patient Identity and Patient Record Matching. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and-patient-record-matching.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="8836"/>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested the need for a national Health Plan ID (HPID) to identify a patient's previous/concurrent payers. The commenter requested that CMS re-work and re-issue required standards for a national HPID. A commenter also stated that the process would benefit from establishing technical standards to ensure that all payers are using the same data elements to verify a patient's payer(s).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge industry's interest in a national standard for a payer identifier. We are aware that there are a few alternative standards used in transactions today, which are located on member ID cards and maintained in payer systems. For example, the Payer ID, used in Electronic Data Interchange (EDI) transactions, is a unique ID assigned to insurance companies to enable them to communicate with each other to verify eligibility, coverage, benefits and submit claims. CMS also maintains a Plan ID for all QHPs on the FFEs, which are 14 alphanumeric characters. Until and unless a national standard is adopted, industry may wish to collaborate with the SDOs on an appropriate payer identifier for the APIs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters raised the concern that for QHPs, the X12 834 transaction standard for health plan enrollment and disenrollment from the FFEs does not currently carry previous payer information, complete information on concurrent payers, member IDs, or opt in needed to support the payer to payer data exchange during QHP enrollment. A commenter also raised concerns about situations where a patient begins the QHP enrollment process but does make the binder payment, and therefore ultimately does not effectuate their coverage.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Requiring payers to gather this information could result in a more streamlined approach than incorporating it into the X12 834 transaction standard enrollment process, given that FFEs are not otherwise required to use or retain the information. However, as discussed previously, we are finalizing a modification to our proposal to account for the timing of QHP coverage effectuation relative to plan selection, which impacts when a QHP can reasonably obtain information from an enrollee. Specifically, QHP issuers on the FFEs will be required to provide enrollees or their personal representatives with an opportunity to opt into the QHP issuer's Payer-to-Payer API data exchange no later than 1 week after the coverage start date or the effectuation of coverage, whichever is later. This timeframe accounts for the date on which an issuer has confirmation that an individual will be enrolled in QHP coverage with the issuer, by receiving the binder payment that is required to effectuate coverage per 45 CFR 155.400(e), as well as instances in which coverage takes effect retroactively.
                    </P>
                    <HD SOURCE="HD3">iii. Currently Enrolled Patients</HD>
                    <P>We proposed that no later than the compliance dates for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous/concurrent payer(s) from all patients who are currently enrolled.</P>
                    <P>Some payers may want to have a soft launch, rolling implementation, or pilot for their Payer-to-Payer API before the compliance dates. We therefore tied our proposal to require impacted payers to gather permission from currently enrolled patients to the proposed 2026 compliance dates, rather than when a payer implements its API. We stated that this would allow payers to sequentially target specific plans, populations, or enrollee categories for operational rollout, as long as all currently enrolled patients are given the opportunity to opt into the payer to payer data exchange by the compliance dates.</P>
                    <P>We received no comments on this proposal. In alignment with the modified compliance dates discussed throughout this final rule, the requirements to request currently enrolled patients' opt in permission and previous/concurrent payer information will be tied to the 2027 compliance dates we are finalizing for the Payer-to-Payer API.</P>
                    <HD SOURCE="HD3">iv. Opt In</HD>
                    <P>We proposed an opt in approach for the data exchange through the Payer-to-Payer API. We stated that an opt in framework means that the patient or their personal representative would need to affirmatively permit a payer to share data, and without that permission, the payer could not engage in the proposed payer to payer data exchange for that patient. We noted that this permission (or lack thereof) would apply only to the data exchange we proposed and would not satisfy any other obligations required under the HIPAA Privacy Rule or other law. Additionally, we stated that we believed patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Should a patient choose to provide this information, it would require an affirmative act from the patient, so we stated that the burden of asking a patient to opt in would not create a significant additional barrier to patient participation. We also proposed to require impacted payers to have a process for patients to opt into this data exchange at any time after the start of coverage, or if they have already opted in, to withdraw that permission at any time.</P>
                    <P>As discussed in section II.C.4.c. of this final rule, this opt in requirement does not apply to data exchanges between a state Medicaid or CHIP program and its contracted managed care plans or entities. We also proposed that states, through their Medicaid and CHIP programs, would be responsible for collecting a patient's choice to opt into the payer to payer data exchange, rather than their contracted managed care plans. We explained that a Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state's Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the managed care plans that they contract with. Thus, we proposed that the patient permission for this data exchange, as a Medicaid or CHIP beneficiary, would be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled.</P>
                    <P>In contrast, our policy for the Provider Access API will allow payers to exchange patient data with providers unless a patient has opted out. We proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the patient and provider, a contractual relationship between the payer and the provider, and a coverage relationship between the payer and patient. Specifically, our policy to only require the Provider Access API data exchange with providers in the payer's network and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the payer that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship, but would be exchanging data based on a patient's separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role for the Payer-to-Payer API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed support for the proposed policy to require patients to opt into the Payer-to-Payer API. Commenters provided various rationales for their 
                        <PRTPAGE P="8837"/>
                        support. Multiple commenters stated that the opt in approach would give patients greater access to and control over their information. Other commenters appreciated that the opt in approach protects patient privacy. Some commenters noted that the opt in approach would be easy for a payer to implement when a patient is a new beneficiary or enrollee because the payer's relationship with the patient is new and active and the payer can request a patient's opt in at the same time as the payer requests the patient's previous/concurrent payer information. A commenter noted that the Payer-to-Payer API is particularly well suited for an opt in approach because it is usually a one-time or time limited exchange (unless concurrent payers are involved).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters feedback in support of an opt in policy and are finalizing this policy as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters voiced concerns about an opt in approach. Multiple commenters expressed concern that an opt in approach will result in lower rates of patient participation in the payer to payer data exchange. Multiple commenters recommended that CMS adopt an opt out approach for the Payer-to-Payer API instead of an opt in approach. Primarily, commenters agreed that an opt out framework would lead to more patient participation and more data available for the new payer, any new network providers, and patients themselves. A commenter was concerned that patients may be confused by the opt in process and recommended providing clear directions to patients detailing how and when patients can opt into data sharing.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that an opt in approach often results in fewer data exchanges than an opt out policy. However, increased data exchange is not necessarily the goal of our policy unto itself, but a process to facilitate improved care. We believe that patients, as they are the owners of their data, should have control over who has access to their data, especially when the two parties exchanging patient data do not have a direct relationship with each other, as in the case with payer to payer exchange versus the Provider Access API where the payer and provider have a network contract. However, we know that the more data available, the more informed decisions about care can be. Patients should see value in having their data exchanged between their previous/current payer(s) and their new payer. As discussed in section II.C.3.g. of this final rule, impacted payers will be required to provide plain language information to patients informing them of the benefits of payer to payer data exchange and directions for opting in.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS better explain the length of time that an opt in election is valid.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The patient's opt in election is valid indefinitely with that payer unless the patient decides to withdraw their permission at a later time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested clarification on the implications of a patient choosing not to opt into the data exchange via the Payer-to-Payer API. Specifically, a commenter agreed that the information proposed for the Payer-to-Payer API can be shared only if the patient opts in, however, requested clarification on how payers could meet obligations to exchange these patients' data for other purposes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Patients have a choice about whether they want their data shared under this policy as they transition between payers. If a patient chooses not to opt into the data sharing, data will not be exchanged between payers under the requirements in this final rule. However, payers may exchange information without a patient's authorization for other purposes, such as benefit coordination in the case of concurrent payers, or for other permissible reasons under the HIPAA Privacy Rule. There is nothing in this rule that would prohibit payers from using the Payer-to-Payer API as the mechanism for data exchange permissible under other authority, even if the patient has not opted into the payer to payer data exchange policy in this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters submitted responses relating the Payer-to-Payer API data exchange to the HIPAA Privacy Rule exception for TPO disclosures, which do not require patient authorization. Some commenters stated that the information CMS proposed to require be made available falls under the scope of that exception and therefore opt in should not be required. Other commenters believe that some of the data (such as prior authorization information) would fall under that exception, but other data (such as claims information) would not. A few commenters suggested that CMS should reduce the scope of the data exchange to allow disclosure under the TPO exception. Furthermore, commenters stated that it may confuse and upset patients who have opted out of sharing their data via the Payer-to-Payer API, but whose PHI may otherwise be disclosed under the HIPAA Privacy Rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We emphasize that our final requirements are not intended to change any existing obligations under the HIPAA Privacy, Security, and Breach Notification regulations, the regulations under 42 CFR part 2, or state privacy or other laws, but can and should be implemented in accordance with those rules. To make a blanket determination that the Payer-to-Payer API exchange that we are requiring always constitutes a TPO disclosure would go beyond the scope of this rule and could overstate and conflict with existing HIPAA Privacy Rule requirements and guidance. Making such a determination could have unintended effects on covered entities' ability to disclose PHI. Instead, for the reasons explained previously, it is appropriate to require patients to opt in for payer to payer data exchange. Our payer to payer data exchange requirements are disclosures permitted under the HIPAA Privacy Rule as “uses or disclosures that are required by law,” as defined at 45 CFR 164.103, rather than as a permitted TPO disclosure. “Required by law” disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard, thereby ensuring that all content required by our Payer-to-Payer API policy may be disclosed. In addition, the data exchange must not be prohibited by other law, such as restrictions on patient records related to substance use disorder at 42 CFR part 2 or state privacy laws.
                    </P>
                    <P>
                        We emphasize that the opt in process described here applies only to the payer to payer data exchange in this final rule. That is, it applies only to the requirement for impacted payers to share individual claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Similar to the discussion in section II.B.3.b.ii. regarding Provider Access API, a patient's choice not to opt into the payer to payer data exchange does not prohibit the payer from using the Payer-to-Payer API to exchange patient data under another permissible authority. For instance, there may be other permissible bases for payers to share data, without a patient's authorization, such as under the HIPAA Privacy Rule's permitted uses and disclosures to carry out treatment, payment, or health care operations. Patients do not have the ability to opt 
                        <PRTPAGE P="8838"/>
                        out of a payer using the API itself as a mechanism for sharing data under such bases for disclosure. We urge payers to inform their patients of this possibility in the educational resources discussed in section II.C.3.g. However, we also note that the HIPAA Privacy Rule, at 45 CFR 164.520, has specific notice requirements for covered entities to send to individuals. Payers should make clear the differences between the payer to payer data exchange, which requires patients to opt in, and other permissible disclosures, which may not require authorization.
                    </P>
                    <P>We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Payer-to-Payer API policy. For instance, a payer may be permitted to disclose PHI to another covered entity to coordinate benefits or determine cost-sharing amounts for the covered entity's payment purposes under 45 CFR 164.506(c)(3). If that disclosure is permissible, a patient declining to opt into the payer to payer exchange policy in this final rule would not prohibit a payer from using the Payer-to-Payer API to make that disclosure. In fact, we encourage payers to leverage the Payer-to-Payer API as a standardized mode of transmitting this information. Payers may leverage a variety of solutions for exchanging coverage data today and moving to a standard-based API across the industry could benefit payers by reducing the types of connections they must maintain to communicate with other payers.</P>
                    <P>Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out treatment, payment, or health care operations. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual's request for a restriction. Where covered entities agree to a restriction, it is bound to the restriction to which it agrees unless the restriction is subsequently terminated. We emphasize that the opt in process described in this final rule is specific to the Payer-to-Payer API policy and is therefore not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).</P>
                    <P>These nuances are necessary for patients to understand that their personal health information may still be shared in some instances, even if they do not opt into the payer to payer data exchange. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS assist states with implementing opt in processes. Another commenter explained that the feasibility of an opt in approach depends on how it would be implemented. A different commenter recommended that CMS to work with stakeholders to develop a standard approach for how an opt in requirement will work when the patient is not the primary insurance holder, noting that a standard approach is necessary to reduce confusion and ensure that patient information is protected.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that the feasibility of an opt in approach depends on how it is implemented, which is why we are leaving the actual implementation process up to the payers. We expect that payers will implement the most viable processes for themselves. Each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. We note that in some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the payer to payer data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual's permission and the previous/concurrent payer should respond in kind with the individual patient's record. No data should be shared about any patient that has not opted in (or whose personal representative has not opted in), regardless of whether another patient covered under the same benefits has opted in.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters weighed in on whether patients' opt in should be collected electronically and specifically recommended that payers collect the opt in via a patient portal or mobile device. A commenter explained that payers do not have the means to collect patients' opt in via multiple methods. A different commenter noted that payers should collect opt in data electronically. Another commenter stated that patients should not be required to use a patient portal or mobile device app to opt into data sharing. A commenter also requested guidance on how to collect permission from patients who require assistance enrolling or registering for the patient portal. Another commenter noted the importance of equitable access to patient data and highlighted the current usage of patient portals as a method to authenticate patients' identities and obtain their opt in permission. They recommended a centralized identity service for patient authentication, verification, or consent for patients who cannot, or prefer not to, access the patient portals. A commenter recommended that CMS provide a centralized security verification through CMS. The commenter noted that a centralized security certification validation would relieve burden on payers to manage connectivity with other payers and provide assurances around self-signed certificates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are finalizing that all impacted payers must develop and maintain processes to identify a patient's previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) no later than 1 week after the start of coverage. As finalized in this rule, each new payer will be responsible for gathering permission through an opt in process before requesting data from any previous or concurrent payer. If payers believe that a patient portal or mobile smart device with appropriate security protections is the best way to gather opt in, it is permissible to use those methods. We are not being prescriptive about the process or procedures used by impacted payers for the required opt in process. However, we strongly recommend that there be a way for patients to record their permission telephonically or otherwise if they do not have internet access or do not want to sign up for an electronic portal. We agree that equitable access to patient data is of the utmost importance and emphasize that the Payer-to-Payer API requirements are intended to allow for other solutions besides patient portals for authentication, verification, or consent. For those patients who require assistance, a personal representative would be allowed to assist. However, we do note that 45 CFR part 92 requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.
                    </P>
                    <P>
                        We also are working closely with ONC on how the Individual Access Services exchange under TEFCA could 
                        <PRTPAGE P="8839"/>
                        support patient access to their data on the network, which could include via payer APIs. We appreciate the suggestion of a centralized security process and will consider our authority in this area.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters generally supported the proposed requirement for payers to implement procedures to allow patients to withdraw permission for the payer to payer data exchange after initially opting in. Several commenters requested clarification from CMS on what action payers must take in such instances. Specifically, multiple commenters recommended that CMS explain whether payers are expected to delete data that have already been received through the Payer-to-Payer API if a patient withdraws their opt in permission after the data exchange has occurred. Another commenter recommended that CMS explain whether patients with concurrent payers will be able to withdraw their opt in permission to stop the quarterly concurrent payer data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Our opt in policy is only prospective. If a patient opts in, their impacted payers would be required to exchange data via the Payer-to-Payer API, if all other requirements are met. If that patient subsequently withdraws permission, payers will not need to take any additional steps with regard to patient data that have already been received from another payer. Specifically, there is no requirement in our regulations to delete those data from their records. We acknowledge that it may not be possible in all cases to clearly delineate which entity created each part of the patient record and trying to do so would put a burden on payers without benefit to patients. Payers are permitted to identify the previous or concurrent payer as the source of data, but are not required to do so. If a patient withdraws their permission for the payer to payer data exchange after first opting in, the payer will not be permitted to request that patient's data from another payer, including a concurrent payer, unless the patient subsequently opts in again. As discussed previously, payers may exchange information for other purposes not related to the policies described herein, such as for benefit coordination in the case of concurrent payers or other permissible purposes under the HIPAA Privacy Rule, and may still use the Payer-to-Payer API as the mechanism to exchange data for those purposes, even if a patient has not opted in.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters made recommendations related to CMS monitoring and oversight of the opt in approach. A commenter suggested that CMS conduct oversight to ensure that payers implement the opt in process and provide appropriate messaging to patients. A commenter recommended that CMS require payers to submit data on the number of patients who opted into the data exchange and how they were educated to do so. The commenter stated that this would help CMS understand if the API is meeting its intended goals. Another commenter recommended that CMS consider including Payer-to-Payer API claims in the Healthcare Effectiveness Data and Information Set (HEDIS) measure. Another commenter recommended that CMS monitor the percentage of patients that do not opt into these data exchanges via the Payer-to-Payer API and assess whether those patients are concentrated in certain populations and whether there are equity issues that CMS should address in the future.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose to require impacted payers to report any metrics regarding the number of patients who opt into data sharing, but we appreciate the recommendation and will consider it for future rulemaking. We note that the specifications of HEDIS measures are out of scope for this rule. We received comments on many of our proposals about the need for specific compliance and enforcement efforts pertaining to each API and we address these comments in section I.D. of this final rule. Oversight and compliance procedures and processes vary among these CMS programs and may have different implications based on a payer's status in the program, previous compliance actions, and corrective action plans.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported our proposal to require state Medicaid and CHIP programs to collect patients' permission for payer to payer data exchange in lieu of their contracted managed care plans and managed care entities. Commenters stated that Medicaid and CHIP agencies are in the best position to collect information from all beneficiaries during eligibility and enrollment. However, commenters warned that if sister agencies within the state perform eligibility and enrollment processes, there would be additional coordination required to collect patients' permission.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that state Medicaid and CHIP agencies are the logical entity to hold Medicaid and CHIP beneficiaries' permission for payer to payer data exchange. We note that MCOs, PIHPs, and PAHPs are still responsible for collecting previous/concurrent payer information and requesting the data exchange. However, nothing in this rule would prevent a Medicaid or CHIP agency from collecting that information and passing it along to their MCOs. We also acknowledge the specific difficulties that states may face to implement the requirements of this rule and refer readers to section II.E. of this final rule for discussion about available extensions and Federal funding for IT expenditures related to these requirements.
                    </P>
                    <HD SOURCE="HD3">d. Requesting Data Exchange From a Patient's Previous/Concurrent Payer(s) and Responding to Such a Request</HD>
                    <HD SOURCE="HD3">i. Timeframe for Requesting Data</HD>
                    <P>We proposed to require impacted payers to request a patient's data from their previous/concurrent payer(s) no later than 1 week after the start of coverage, as defined previously. We stated that 1 week should be sufficient time for payers to complete their process for identifying patients' previous/concurrent coverage and to request data from the other payer(s). We proposed that if, after the start of coverage, a patient opts into the data exchange or provides previous/concurrent payer information or requests a payer to payer data exchange for another reason, then the current payer would be required to request data from the previous/concurrent payer(s) no later than 1 week after the payer received the previous/concurrent payer information and the patient has opted in, or the patient makes the request. We acknowledge that the obligation to request data is contingent on the patient supplying the necessary information about a previous/concurrent payer to enable the new payer to conduct the required exchange. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. In that case, payers are required to make reasonable efforts to gather this information from patients. For example, we recommend payers follow-up one time before determining that the patient has not opted in. We are finalizing a modification to the proposed regulatory text to clearly establish that the 1-week timeframe for requesting patient data begins when the impacted payer has sufficient identifying information about previous/concurrent payers and the patient has opted in.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported our proposal to require impacted payers to request data from a patient's previous payer no later than 1 week after the start of coverage or obtaining previous/concurrent payer 
                        <PRTPAGE P="8840"/>
                        information and opt in permission from the patient. Other commenters suggested a variety of alternative timeframes for payers to request patient data from previous/concurrent payers. A few commenters recommended that CMS allow 2 weeks after the start of coverage to request the data. Other commenters recommended that CMS extend the timeframe for a data exchange to be within 30 or 90 days after enrollment to allow payers time to confirm the patient's information, especially during peak volumes such as open enrollment. A commenter highlighted that a 90-day timeframe would allow time for the previous payer to process outstanding claims. Conversely, other commenters recommended a 3-day timeframe for a new payer to request the patient's data from their previous payer to expediate the data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We continue to believe that 1 week is the appropriate period to require payers to make a request for patient data after they have sufficient identifying information about the previous/concurrent payer and the patient has opted in. The longer the period between the time a patient enrolls with a new payer and that payer receives patient data, the less relevant those data could be. This is particularly true for patients who have chronic conditions or ongoing treatment for life-threatening conditions. For these patients, it is more important that their new payer get information as soon as possible. If necessary, additional information can be exchanged as it becomes available. See our discussion in section II.C.3.d.i. of this final rule regarding optional additional data exchanges between previous and new payers. For instance, the CY 2024 MA and Part D final rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA plan. During that time, the new MA organization may not require prior authorization for an active course of treatment. Establishing a 90-day timeline for payer to payer exchange could largely negate the utility of the data to comply with that requirement. Even a shorter period, such as 2 weeks or 30 days, could require patients to provide separate information about active courses of treatment, which would add burden to patients rather than reducing it. Regardless of whether impacted payers are subject to that rule, it is important to exchange data quickly so that patients can maintain a continuity of care.
                    </P>
                    <P>However, we also determined that our proposed data request deadline was no longer feasible with the modified deadline for requesting previous/concurrent payer information and the patient's opt in to be no later than 1 week after the start of coverage. Therefore, we are also finalizing a modification to our proposal to require impacted payers to request data from a patient's previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in, or within 1 week of a patient's request. We encourage payers to request these data as expeditiously as possible. Specifically in regard to periods of peak volume for payers, we encourage payers to use the Bulk Data Access IG to send bulk requests and responses for multiple patients at once. As discussed in section II.G. of this final rule, we are finalizing our proposal to require payers to implement the Bulk Data Access IG for the Payer-to-Payer API for this very purpose.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters suggested that CMS explain the meaning of within 1 week of the start of coverage. A commenter highlighted how Medicaid policy requires that they grant eligibility retroactively up to 3 months and recommended that the data request within 1 week of the start of coverage be based on the date that the eligibility update is received into their MMIS, not the effective date of coverage, which could be 3 months prior. Another commenter recommended that only QHP policies that have been effectuated with a binder payment be subject to the payer to payer data transfer requirement, which should leave 1 week after the date that benefits begin for the new payer to request the data transfer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As noted previously, we are changing the deadlines for payers to request information from other payers by tying them more closely to the date when the payer has sufficient information about a patient's previous and concurrent payers and the patient has opted in. As such, the data request deadline is no longer linked to the start of coverage or enrollment. Further, as explained previously, the term “start of coverage,” as used in the preamble to this rule, means when coverage begins or when the patient enrolls, as applicable. For cases when there may be retroactive coverage, such as in Medicaid, the payer will be required to seek a patient's opt in for Payer-to-Payer API data exchange and to request information about a new patient's previous/concurrent payer(s) no later than 1 week after the patient's enrollment. In Medicaid, the patient's “enrollment” is the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date that coverage takes retroactive effect. For that reason, the regulation text in Medicaid FFS reflects this by referring to “enrollment” instead of “start of coverage.”
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested clarification that timing requirements are flexible to the extent reasonable and necessary to verify that privacy and security requirements are met. A commenter emphasized that this timeframe could only be followed if it begins after the member has provided sufficient information as determined by the impacted payer to identify a concurrent payer (for example, payer name, member enrollment number, group number).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that the timeframe for sending a request only begins when a payer has sufficient information to send a request to another payer and the patient whose data are being requested has opted in. We are finalizing that the request must be made no later than 1 week after the payer has sufficient identifying information and the patient has opted in. We note that, as discussed previously, payers have an obligation to request that information from their patients no later than 1 week after the start of coverage, as that term is defined previously specific to each impacted payer type.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that if payer endpoints are not publicly available or accurate information on a previous payer is not available, payers should only be required to make reasonable efforts to complete the data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Existing requirements require payers to make technical documentation about their API, including digital endpoint information, on a publicly accessible section of their website.
                        <SU>83</SU>
                        <FTREF/>
                         In section I.D. of this rule we discuss an NDH that could serve as a centralized place for impacted payers to find other payers' digital endpoints. Commenters indicated that such a directory would significantly improve the process for requesting patient data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care, 42 CFR 457.730(d) for CHIP FFS, 42 CFR 457.1233(d) for CHIP managed care, and 45 CFR 156.221(d) for QHP issuers on the FFEs. These requirements are cross referenced in the regulations requiring impacted payers to apply the same technical specifications to all the APIs required under this final rule.
                        </P>
                    </FTNT>
                    <P>
                        Payers are required to request patient information from previous and concurrent payers if the conditions in the rule are met, and we encourage payers to make a reasonable effort to locate information about a patient's 
                        <PRTPAGE P="8841"/>
                        previous payer. If a payer is unable to obtain a valid endpoint or accurate information for a previous or concurrent payer, we recommend they document the efforts they took to gather the information from the other payer. Doing so could establish a record for future oversight, or in case of a dispute, that the payer made a reasonable effort to comply with the requirements of this rule and the patient's desire for their data to be exchanged. As discussed, payers are not responsible for determining whether the patient's previous payer is an impacted payer, but are required to request previous/concurrent payer information from the patient and to make the data request to the other payer. We encourage payers that are not subject to the requirements in this rule to participate in the Payer-to-Payer API exchange in order to allow their patients to benefit from this policy. However, a payer not subject to this regulation may not have a FHIR API or want to exchange the required information, which would be outside of the impacted payer's control.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters flagged that impacted payers will need time to establish the necessary technology linkages, data use agreements, and security protocols to exchange information with another payer in a manner compliant with the HIPAA standard transaction and code set requirements. A commenter noted that the data exchange would take longer than 1 week if a payer needs to set up a new connection, as feeds may differ.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that a functional technological connection with other payers to meet the requirements for the Payer-to-Payer API policy can and sometimes will take more than a week to complete. However, there is no applicable HIPAA standard transaction or code set for the payer to payer data exchange we are finalizing in this final rule. The required standards are those being established in this final rule. Giving impacted payers sufficient time to coordinate with other payers to establish the capability to exchange data is one rationale for delaying the compliance dates from the proposed 2026 to 2027. We expect that payers will use that additional time not only to build the requisite API technology, but to coordinate with other payers to establish those linkages. We encourage payers to establish connections and perform testing with other payers before the compliance dates for the Payer-to-Payer API to ensure that the data exchange will work as expected. Payers should also set up a testing or sandbox instance of their Payer-to-Payer API as early as possible for other payers to test against. We also encourage payers to establish data use agreements and register with each other's APIs prior to the compliance dates in order to facilitate exchange as quickly as possible after the compliance dates. We expect that those technological and legal requirements will be most burdensome when one payer connects with another for the first time. Subsequent exchanges should rely on that same foundation, and it should not be necessary to repeat those steps. Finally, we suggest payers prioritize other payers that they are most likely to exchange with, such as those that overlap with their geographical coverage area.
                    </P>
                    <HD SOURCE="HD3">ii. Additional Data Exchange</HD>
                    <P>In the proposed rule, we solicited comments on whether additional data exchanges would be warranted to account for data received or processed by the previous payer after the patient's coverage ends and, if so, what the appropriate parameters would be. Outside the context of concurrent payers, we generally expect our policy to require a one-time data exchange between a previous and new payer. Once the new payer has received the patient's data from the previous payer, we do not generally expect there to be additional exchanges with the previous payer. However, we want to allow patients to request subsequent data exchanges to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have enrolled with a new payer, thus creating additional data within the patient's record for some time period after the patient has changed payers. We considered proposing a policy where, if the patient opts in, a previous payers would be required to send any additional data within the required dataset to the new payer no later than 1 week of receiving the additional data. However, keeping in mind the burden this could impose on payers, we sought comment on such a policy. We sought comment on whether additional data could be helpful for the new payer in the weeks or months after enrollment, and which specific data could be most pertinent, or whether additional data exchange would be overly burdensome and not provide value to the new payer. We asked whether it would be appropriate to limit such a requirement to send updated data to a certain period after the initial data exchange, for instance within 30 or 90 days. Additionally, we asked whether impacted payers should be required to make an additional data exchange within a week of receiving any new data or on a set cadence, such as monthly or quarterly, to allow payers to streamline transactions for multiple patients.</P>
                    <P>
                        <E T="03">Comment:</E>
                         We received varying comments around additional data exchanges with multiple commenters supporting a one-time additional data exchange to promote continuity of care. Some commenters thought it would not be feasible to share additional data within 1 week of each update but supported a single exchange at 30-, 60- or 90-days after the patient has moved to a new payer. A commenter stated it would be difficult to track when additional data need to be sent after the initial exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that it could be helpful for payers to supplement the data exchange required under this rule, to account for any claims or data that are received after the initial data are sent to the new payer. While we are not requiring it, we encourage payers to do so in order to pass along a complete patient record. Likewise, we encourage the new payer to send an additional request for data within 90 days of receiving the initial data response. The previous impacted payer would be required to respond to such a request.
                    </P>
                    <HD SOURCE="HD3">iii. Authorization and Authentication Protocols</HD>
                    <P>We proposed that impacted payers would be required to use the OpenID Connect Core authorization and authentication protocols at 45 CFR 170.215(e)(1) to authenticate the identity of the requesting payer. We wanted to ensure payers would not have to send data unless they are confident that the requesting payer is identified. The ONC Cures Act final rule adopted content and vocabulary standards to provide the foundation needed and were finalized for use in the CMS Interoperability and Prior Authorization final rule to support implementation of the policies (85 FR 25521-25522). Thus, we proposed OpenID Connect Core in effort to align standards across API implementations.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters sought clarification on the general authentication and authorization process and flagged that requiring OpenID Connect Core will not be sufficient for the Payer-to-Payer API. A commenter recommended that CMS consider UDAP or the PDex IG, which uses a SMART framework instead. Another commenter flagged that the OpenID Connect Core standard requires a log-in, whereas the proposal suggested that payers are required to provide these APIs without a user login or credential. 
                        <PRTPAGE P="8842"/>
                        A commenter highlighted that the Bulk Data Access IG requirement relies on portal credentials and user logins created by the individuals to be linked to their identity in the payer system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Upon consideration, we agree that it would not be appropriate to require OpenID Connect Core for the Payer-to-Payer API. OpenID Connect Core is a means to identify individuals and because the Payer-to-Payer API is a business-to-business interaction, OpenID Connect Core is not adequate to meet this use case. Although OpenID Connect Core can be utilized for the Payer-to-Payer API, it is not a scalable approach because it requires user credentials. For similar reasons, we are finalizing a modification to our proposal to not require OpenID Connect Core for the Provider Access, Payer-to-Payer and Prior Authorization APIs.
                        <SU>84</SU>
                        <FTREF/>
                         The SMART App Launch IG can also provide a method for authentication within the Payer-to-Payer API; though we note that we are not finalizing our proposal to require that IG, it remains available to payers as an option. However, as part of the Payer-to-Payer API, payers still need to authenticate bi-directionally using industry best practices to ensure that patient data are only shared appropriately. We refer readers to Table H3 in section II.G. for an updated listed of required and recommended standards and IGs. We also advise that the Bulk Data Access IG, which is a required IG for the Payer-to-Payer API, contains a “SHOULD” (that is, strongly recommended) conformance statement to use SMART Backend Services. We also note that SMART Release 2.0.0, which has since been adopted in the HTI-1 final rule at 45 CFR 170.215(c)(2) includes SMART backend services. Though in this final rule we are requiring impacted payers to support the Bulk Data Access IG in their Provider Access and Payer-to-Payer APIs, this requirement does not obligate them to use it for every data exchange if it is not necessary.
                    </P>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             In the proposed rule, that requirement was included for MA organizations at 42 CFR 422.121(b)(1)(i), for Medicaid FFS at 42 CFR 431.61(b)(1)(i), for CHIP FFS at 42 CFR 457.731(b)(1)(i), for Medicaid managed care plans through cross reference at 42 CFR 438.242(b)(7), for CHIP managed care entities through cross reference at 42 CFR 457.1233(d), and for QHP issuers on the FFEs at 45 CFR 156.222(b)(1)(i).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS collaborate with industry stakeholders to identify best practices for user authentication and authorization with the Payer-to-Payer API. Another commenter highlighted that guidance on how to trust and verify inbound data requests via the Payer-to-Payer API will be essential.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We will continue to collaborate with industry stakeholders through HL7 FHIR workgroups and through HL7 FHIR Connectathons as the standards to support the Payer-to-Payer API continue to be refined to support these final policies. We also will continue to work closely with ONC on the required authentication and authorization standards under 45 CFR 170.215. While we are not specifically requiring an IG or method be used for authentication and authorization, as part of the Payer-to-Payer API payers still need to authenticate the other payer they are exchanging data with.
                    </P>
                    <HD SOURCE="HD3">iv. Attestation</HD>
                    <P>We proposed to require the requesting impacted payer to include an attestation with the request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the applicable legal requirements. As explained in section II.G. of this final rule, we recommended certain HL7 FHIR IGs to support the data exchange between payers. The recommended PDex IG has been developed to include both the technical and business processes of capturing and sharing a patient's permission for data exchange with the payer to payer data request. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations, which could meet or exceed the requirements of the PDex IG.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the attestation proposals for the Payer-to-Payer API. Multiple commenters provided recommendations for processes to share patients' data sharing permission. Multiple commenters suggested processes for payers to verify that a patient opted into data sharing with another payer before giving that payer access to patient data. A commenter requested clarification on whether patients must opt in for each subsequent payer. A commenter recommended that patients' data sharing permission be shared with secondary and tertiary payers. Commenters requested clarification on which payer (the requestor or requestee) is responsible for obtaining patients' permission. A commenter highlighted that an attestation process will not resolve the risks of incorrectly matching data to the patient. Another commenter asked whether FHIR can be used to send the attestation. Another commenter requested clarification on using standards and IGs to facilitate the opt in process. A commenter sought guidance on where a patient's opt in would be indicated on the electronic transmission and how they could verify that the payer provided educational information to the patient.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the recommendations for sharing a patient's opt in but leave that exact process up to payers. The impacted payer requesting the data from the previous/concurrent payer is responsible for obtaining the patient's opt in and must include an attestation with that request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the necessary legal requirements. Patients would have to opt in for each subsequent payer to request their data from a previous/concurrent payer. The purpose of the attestation is not to match the data to the patient, but to affirm that the patient has enrolled with the requesting payer and has opted into the data exchange in a manner that meets the necessary legal requirements. We highly recommend using the IGs discussed in further detail in section II.G. of this final rule to support the Payer-to-Payer API. The latest published version of the PDex IG (STU 2.0.0) includes a means for a payer to communicate that the member has opted in—through a FHIR Consent resource—when requesting data from another payer. An attestation or verification that the requesting payer provided educational information to the patient is not required to be sent with the request.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS more clearly explain the Payer-to-Payer API process to ensure that prospective or potential payers are not requesting a patient's data. Another commenter suggested that an attestation from another payer is not sufficient proof to demonstrate a patient's decision to opt in and suggested that some assignment of legal liability be considered for the requesting payer, as it might assuage these concerns.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         A prospective or potential payer should not request a patient's data under this rule. Under this rule, a payer must attest that the patient is enrolled with that payer as part of its request for the patient's data from a previous/concurrent payer. We emphasize that the impacted payers must implement an authentication process (discussed previously) that verifies the requesting payer's identity as a legitimate health care coverage entity. If an entity includes a fraudulent attestation that the patient is enrolled with the payer and has opted in to payer to payer data 
                        <PRTPAGE P="8843"/>
                        exchange in its request for patient data, that entity could be subject to criminal or civil penalties.
                    </P>
                    <HD SOURCE="HD3">v. Timeframe for Responding to a Request</HD>
                    <P>We proposed that impacted payers that are previous/concurrent payers would be required to respond to a current payer's request, if specified conditions are met, within 1 business day of receiving the request. We explained that 1 business day would be the appropriate timeframe to complete this process to send the data, as new payers need timely access to previous/concurrent payer data to facilitate care coordination and make the information available to providers within their new network. We noted that this timeframe also would align with the 1 business day response time for the Patient Access and Provider Access APIs.</P>
                    <P>We sought comment on whether the proposed timeframes for the previous/concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We sought comment on whether payers need more than 1 business day to respond to a request and sought comments on what might be a more appropriate timeframe if commenters thought a different timeframe was warranted. We explained that it is important for patient data to move to the new payer as soon as possible to send their patient record and to ensure care continuity.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for the 1 business day response time for the Payer-to-Payer API. A commenter recommended a modification that data should be available within 1 calendar day. Another commenter stated that the purpose of standardized API data exchange is to have real-time data availability. A commenter requested that CMS provide at least 24 hours for data from the Prior Authorization API to be available via the Payer-to-Payer API. Some commenters expressed general concern with our proposed response timeframe and suggested that payers may become overwhelmed, especially during open enrollment periods. A commenter expressed concern that the proposed timeframe does not consider the degree of manual effort required to ensure compliance with applicable state laws and regulations regarding health privacy and confidentiality. Multiple commenters recommended that CMS require a response time of 2 business days for the Payer-to-Payer API and another suggested 3 business days.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After reviewing the comments, we believe that keeping the response timeframe at 1 business day is appropriate. This expedient data exchange will support care continuity and still allow time for the processes for payers to appropriately send patient data. We note that this timeframe also aligns with the finalized 1 business day response time for the Patient Access and Provider Access APIs. We acknowledge that some periods may have increased data exchange requests, such as during open enrollment period, and note that the purpose of the required Bulk Data Access IG is to efficiently exchange large volumes of data for multiple individuals and can be utilized for both requesting and sending data.
                    </P>
                    <P>The data content we are finalizing that must be included in the payer to payer data exchange is generally the same as the current requirements for the Patient Access API, notwithstanding the addition of prior authorization information. Claims and encounter data and all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) are structured data, which will help payers identify particular items that are subject to additional privacy requirements. We are also finalizing 2027 compliance dates, in part, to give payers additional time to develop internal processes and train staff. That includes processes make the necessary determinations as to which data are permitted to be shared via the Payer-to-Payer API. For instance, payers may use this time to develop processes that flag certain data elements with metadata—as the payer receives them—if they require special permissions or are prohibited to disclose under other law. We highly encourage payers to engage in this process as they receive data to ease any manual review and decision-making that might be necessary when a payer requests patient data.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS address the need for a legal governance framework for the payer to payer data exchange because the technical standards proposed would not enable the requesting payer to substantiate the patient's authorization. The commenter stated the need to provide legal assurances that the payer requesting a patient's records has obtained appropriate authorization to request the records and without a standardized governance framework, payers would struggle to fulfill the requirement to respond within 1 business day of receiving a request.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand the importance of legal assurance between payers to ensure the patient has provided appropriate authorization before sharing data across payers. The recommended PDex IG STU 2.0.0, which has since been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, includes both the technical and business processes to capture and share a patient's permission as part of the payer to payer data request. We believe 1 business day is sufficient to fulfill the request for data exchange because the IG is a means for payers to electronically send a record of the patient's permission to receive data from the other payer. We are also working closely with ONC as to how TEFCA could support scalable governance for payer to payer data exchange. We reiterate that we are requiring that the new payer provide an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted into the data exchange.
                    </P>
                    <HD SOURCE="HD3">vi. Payers Not Subject to This Regulation</HD>
                    <P>If a previous/concurrent payer is not an impacted payer, they are not subject to our final requirements and, therefore, are not required to send or request data through the Payer-to-Payer API. For example, an employer-based commercial plan would not be subject to this rulemaking. If the previous/concurrent payer is not an impacted payer, they are not subject to our requirements to respond to the request. A new or concurrent impacted payer is not obligated to determine whether the previous/concurrent payer is an impacted payer under this final rule or to limit its requests for a patient's data (or its responses to requests for a patient's data) to only impacted payers. Therefore, we proposed that an impacted new payer would be required to request the data from the patient's previous/concurrent payer, regardless of whether the other payer is an impacted payer. Conversely, we proposed that if an impacted payer receives a request for patient data that meets the requirements of this rule, they would be required to respond by making available the required data through their Payer-to-Payer API, regardless of whether the requesting payer is an impacted payer (which the payer may or may not know).</P>
                    <P>
                        If a payer not subject to this regulation does not have the capability or refuses to exchange the required data with an impacted payer or is willing to exchange the data but is unable or unwilling to do so through a FHIR API, the impacted payer will not be required to exchange data with that payer. Payers that have not implemented the Payer-to-Payer API would not have accessible digital endpoints to make the required request. 
                        <PRTPAGE P="8844"/>
                        We emphasized in the proposed rule that impacted payers would not need to spend resources determining whether other payers are subject to this rulemaking, but would be required to request patient data, if possible, and respond to all requests that are made within the requirements. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with other payers, even if they are not subject to our final requirements to support care coordination and more efficient operations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters flagged concerns regarding interoperability with payers not subject to this regulation. A commenter stated that it is unclear what value would be derived from the investment if there is no response or reciprocation from payers not subject to this regulation. Another commenter noted that payers need to build a connectivity system with other payers, including payers not subject to this regulation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree that the burden of connecting with a payer not subject to this regulation that has implemented a Payer-to-Payer API in conformance with our requirements is any different than connecting with an impacted payer. Regardless of whether they are covered by an impacted payer, there is value in maintaining a patient's data and exchanging those data when a patient transitions to a new payer or between concurrent payers. Furthermore, requiring impacted payers to exchange data only with other impacted payers would require impacted payers to expend effort to determine whether the other payer is an impacted payer. That effort can be eliminated by simply treating any payer as a possible exchange partner. Furthermore, not requiring impacted payers to exchange data with payers not subject to this regulation would mean that there would be no incentive for those payers to adopt the requirements of payer to payer data exchange. In addition, impacted payers are not required to exchange data outside of the process finalized in this final rule, including using a standards-based API. If a payer not subject to this regulation requests data in a format that is not compatible with the Payer-to-Payer API and specific data formatting, content and vocabulary standards established in regulation, impacted payers will not be required to send data via a different method, unless other law requires them to do so.
                    </P>
                    <P>We understand that impacted payers may have additional difficulty ascertaining that another payer is not subject to this regulation (or not compliant), as that payer would not have digital endpoints to discover. Payers are required to take reasonable steps to determine whether they can exchange data with the other payer. We encourage payers to contact the previous payer directly to determine whether they support the Payer-to-Payer API. Other solutions could also be explored to help payers determine whether the previous payer supports the Payer-to-Payer API, such as using TEFCA. In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers' digital endpoints and identify payers that support the Payer-to-Payer API. Once a payer knows that another payer is not capable of payer to payer data exchange, they would not be required to inquire every time they receive a new patient who identifies that previous payer. However, it would be prudent to occasionally (such as annually) check whether the other payer has implemented a Payer-to-Payer API and is now capable of data exchange.</P>
                    <HD SOURCE="HD3">e. Ongoing Data Exchange Requirements for Concurrent Coverage</HD>
                    <HD SOURCE="HD3">i. Concurrent Coverage Data Exchange</HD>
                    <P>For individuals who have concurrent coverage with multiple payers, we proposed to require impacted payers to collect identifying information about any concurrent payer(s) from patients before the start of coverage with the impacted payer (consistent with how “start of coverage” is explained previously). Because we believed it would be beneficial for all of a patient's current payers to maintain a complete record of the care that the patient has received, we proposed to require impacted payers to request the same patient data described in section II.C.3.b. of this final rule from all of a patient's concurrent payers, and to send those data in response to a request that meets all the requirements of this final rule. We stated that this would ensure that the patient's concurrent impacted payers maintain a complete patient record and can provide all the information proposed to be required under the Patient Access and Provider Access APIs.</P>
                    <P>
                        Specifically, we proposed to require impacted payers, no later than 1 week after the start of a patient's coverage,
                        <SU>85</SU>
                        <FTREF/>
                         to request data from any concurrent payers that the patient reports. Because all payers will update patient records while a patient is enrolled with those payers, we proposed that when a patient has concurrent coverage with two or more payers, the impacted payers would be required to exchange with every other concurrent payer, at least quarterly. We proposed that should an impacted payer receive a request for a current patient's data from a concurrent payer for that patient, the receiving payer would have to respond with the appropriate data within 1 business day of receiving the request. Operationally, this proposed exchange would function the same as the data exchange with a patient's previous payer.
                    </P>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             For QHP issuers on the FFEs, no later than 1 week after the effectuation of enrollment.
                        </P>
                    </FTNT>
                    <P>We also proposed that any impacted payer that receives patient data from another payer under these regulations must incorporate those data into the recipient payer's records about the patient. The required data content we proposed are the same claims and encounter data (excluding provider remittances and cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. We stated that that proposal would require impacted payers to both request patients' data from other concurrent payers and to respond to requests from other payers to share patients' data.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that we only require concurrent payers making quarterly data transmissions to send data that have been updated since the last data exchange. The commenter stated that this would reduce burden by allowing them to exchange a smaller set of data that can more easily be integrated into their patient records.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that this is a reasonable solution to reduce burden. We are finalizing a modification to our proposal to allow concurrent payers to agree to exclude from ongoing quarterly data exchange any data that were previously transferred to or originally received from the other concurrent payer. We leave it to payers to determine the best process to effectuate this option, as it is intended to reduce payer burden. If exchanging only new data would increase burden on payers versus exchanging all patient data, they are not required to do so. Ultimately, the exchange should result in both concurrent payers having a complete set of patient data to support patient care and care coordination.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS require payers to clearly document, in the payer systems, which payer is primary, and which is secondary to ensure providers receive accurate and timely coordination of benefit information.
                        <PRTPAGE P="8845"/>
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Coordination of benefits is an established process (though the exact process may vary by payer and jurisdiction) that we specifically did not propose to affect. As discussed previously, if payers find it beneficial to use the Payer-to-Payer API for purposes other than the data exchange finalized in this rule, such as coordinating coverage, they are welcome to do so. To the extent that such coordination information would benefit patients or providers by being available via the Patient Access and Provider Access APIs, we encourage payers to do so.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed opinions on the appropriate timeframe for payers to request data from another concurrent payer and for payers to respond to such a request. Multiple commenters stated their general support for timely information exchange between concurrent payers to help minimize unnecessary administrative paperwork and other inefficiencies. Several commenters supported our proposed timeframes. Other commenters suggested that payers have up to 30 days to request patient information. A commenter stated that the data should be available within 1 calendar day instead of 1 business day. A commenter recommended CMS allow at least 3-5 business days for a response.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         There should be no procedural or technical difference between requesting data from a previous payer or a concurrent payer, other than the requirement that concurrent payers engage in ongoing quarterly exchange. Similarly, responding to such a request should be the same process, using the same FHIR standards. Therefore, we believe it is prudent to establish the same timeframes for the initial requests to and all responses from concurrent payers as for previous payers. Therefore, we are finalizing that for concurrent payers, the initial request for data must be made no later than 1 week after the payer has sufficient identifying information about concurrent payers and the patient has opted in and quarterly thereafter. We are finalizing our proposal that impacted payers must respond within 1 business day to a request for patient data from a concurrent payer that meets all the requirements of this final rule.
                    </P>
                    <HD SOURCE="HD3">ii. Concurrent Payer Exchange Timeframe</HD>
                    <P>We also considered whether to propose more frequent exchanges (weekly or monthly), or less frequent exchanges (semi-annually or annually) for the required data exchanges between concurrent payers; however, we explained in the proposed rule that we believed a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. We believed that sharing data quarterly would be frequent enough to allow new health data to accumulate and still be timely, but not so frequent that it causes unnecessary burden on the payers. We requested comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A significant majority of commenters supported our proposal to require quarterly data exchange between concurrent payers because it would facilitate care coordination. Some commenters suggested that a more frequent data exchange could benefit patients. Some commenters noted that even quarterly data exchange may miss key clinical events that would be useful for care coordination and recommended that the data exchange should take place monthly. On the other hand, a few commenters stated that impacted payers should only request additional data from concurrent payers when initiated by a member.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the majority of commenters that a quarterly cadence appropriately balances the benefits and burdens on payers. Payers may make arrangements with each other to exchange information more frequently, if they believe it would benefit their mutual patients. The burden of initiating the exchange should not fall on the patient, especially at times when they are dealing with specific health issues that would most benefit from care coordination. As some commenters recommended more frequent data exchange, we will consider whether to propose amendments to this policy in future rulemaking after the industry has experience meeting the requirements of this final rule.
                    </P>
                    <P>We note that when a patient has concurrent coverage, the payers must communicate regularly to ensure that the proper payer is responsible for that patient's claims. Nothing in this final rule, including a patient not opting into the Payer-to-Payer API data exchange, is intended to alter payers' ability to exchange data as they do today for that purpose, in accordance with applicable law.</P>
                    <HD SOURCE="HD3">f. Data Incorporation and Maintenance</HD>
                    <HD SOURCE="HD3">i. Data Incorporation</HD>
                    <P>We proposed that data received by an impacted payer through this data exchange must be incorporated into the patient's record with the new payer. We stated that those data could then be part of the patient's record maintained by the new payer and should be included as appropriate in the data available through the Patient Access, Provider Access, and Payer-to-Payer APIs. In this way, a patient's data could follow them between payers and be available to them and their providers. We stated that this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, but we encouraged impacted payers to do so, at least to the extent it might benefit the patient's ongoing care. We explained that payers could choose to indicate which data were received from a previous payer so a payer, provider, or the patient looking at the record, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do. Regardless, all data received, maintained, used, or shared via the proposed Payer-to-Payer API would be required to be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported our proposal to require payers to incorporate data they receive from other payers via the Payer-to-Payer API into their own patient records in order to ensure that a patient's record is not lost. Other commenters stated that they do not believe that payers are the appropriate holders of a patient's full medical record and that providers or patients themselves should be the maintainers of those data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that in some cases a payer is not the best entity to hold a patient's longitudinal record and that there is other technology available for patients to download their data, for example, using the Patient Access API, and to store it independently of their payer. As discussed previously, we are finalizing a policy that limits the payer to payer data exchange to data with a date of service within 5 years of the request. After considering public comments, we determined that a 5-year period balances the benefits of new payers having access to recent patient data and the patient not losing recent information against the burden of integrating and maintaining historical data that may or may not be useful to care.
                    </P>
                    <P>
                        For patients who want to maintain their own information in a PHR, they have that option through the Patient Access API. While in some cases, a patient may have a provider that can and will aggregate their records from each other provider that the patient 
                        <PRTPAGE P="8846"/>
                        sees, we do not believe this is a common scenario, as it would require a significant amount of work by the provider. As discussed, because payers receive claims or encounter data from each provider that sees a patient, they typically possess the most complete historical patient record. Requiring a payer to send a patient's data to their new payer will ensure that recent information that could be important for care continuity is not lost.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter cautioned that CMS should not assume that the information received from a previous payer is whole and/or correct. The commenter noted that the difference in health plans' level of diligence could cause some discrepancies in patient coverage. Another commenter suggested that payers would be incentivized to send incorrect information to another payer rather than correcting the patient's record.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that any set of patient data may have errors or omissions. However, we do not believe that the appropriate response to this issue is to discard data when a patient moves between payers. As stated, we do not wish to burden payers to proactively verify patient records when they receive them from another payer. However, under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals generally have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. That right exists regardless of whether the covered entity created the PHI itself or received it from elsewhere. That requirement is consistent with our policy, as it does not require proactive verification, but must be addressed upon request by an individual.
                    </P>
                    <P>We also do not believe that there is any risk of payers intentionally proliferating inaccurate information. There is no reason for a payer to maintain inaccurate records with the ultimate goal of passing that information to another payer when the patient leaves their coverage. Finally, payers are only responsible for maintaining their own records, including that which has been received from another payer. If there is an error to be corrected in data received from a previous payer, neither the patient nor their payer will need to contact the previous payer to correct it and have the patient's record resent. A patient's current payer is required, by the HIPAA right to amend and correct data in its records, even if that incorrect information was initially received from a previous payer.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that all the APIs should support optional provenance resources that could be added by either the sender or the receiver to indicate the source of data. A commenter recommended that instead of CMS recommending payers to note where the data originated, CMS instead propose that specific provenance resources be required to indicate which data came from a previous payer, which could also be included in subsequent data exchanges.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         When incorporating the data from an old or concurrent payer, payers are free to indicate the provenance of that information, which would then be included in the data available through the Patient Access or Provider Access APIs. As discussed in section II.G., we are recommending, but not requiring, the PDex IG for the Payer-to-Payer API. The PDex IG requires provenance information be included in outbound FHIR transactions and that a payer receiving such a transaction must incorporate any included provenance information. There is also a “SHOULD” recommendation within the IG that payers create provenance records when the provenance is not included in a data set (for example, when it was received through non-FHIR mechanisms). We highly recommend that payers use the IG for several reasons, including that it would help address this issue and help payers, providers, and patients understand the source of data. We will consider whether to propose to require provenance information through future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters highlighted that our Payer-to-Payer API policy would require extensive data translation and de-duplication. They suggested that CMS encourage payers to work with HIEs to determine the best solutions to avoid data duplications and associated errors. A commenter expressed concern regarding the potential for duplicate data to be transmitted throughout the health care system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions that there are existing marketplace solutions to address some of the concerns about data duplication. We understand the concern over duplicative information. There are IT solutions, such as EHR vendors and HIEs, available that can make the data actionable and help payers avoid receiving duplicative information via the Payer-to-Payer API. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate payer to payer data exchange. We note that nothing in our policies prohibits a payer from using an intermediary to aid with various functions, such as patient matching, data exchange, or data hygiene.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that they believe data acquired via Payer-to-Payer APIs should be dated with the original date of service to prevent duplication in future Patient Access or Provider Access API requests, if a patient or provider already had that information from the previous payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that it is important to maintain the fidelity of data received via the Payer-to-Payer API. While creating additional metadata is recommended to be able to track where the data came from and when it was acquired, payers should not be changing the underlying data itself. For example, the “date of service” or “date claim processed” should not be updated to the date that the new payer receives the record of the claim from a previous payer.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated claims are not typically considered “patient records” and suggested CMS define the “patient record” into which information from a previous/concurrent payer must be incorporated.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not need to define “patient record” as we are defining the set of data that must be shared between payers, that is, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Furthermore, we have defined maintain in the Interoperability and Patient Access final rule “to mean the payer has access to the data, control over the data, and authority to make the data available through the API” (85 FR 255380). Payers must incorporate patient data into the appropriate place where they maintain that type of information that they generate while covering a patient. We understand that payers will store that information in a variety of ways, depending on their own data infrastructure.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested clarification as to how payers should integrate data into a patient's records if the data from their previous payer includes information from other individuals who were on the same coverage plan (for example, a family health plan).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Each of our policies in this final rule are tailored toward individual patients, not any family members that may be covered through the same 
                        <PRTPAGE P="8847"/>
                        benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the Payer-to-Payer API data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual permission and the previous/concurrent payer should respond in kind with the individual patient's record. No data should be shared about any patient that has not opted in, regardless of whether another patient covered under the same benefits has opted in.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter cautioned that when a new payer takes on another payer's information, this may cause a significant amount of risk for patients as they may get billed for services that are not approved under their new payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are not requiring impacted payers to honor another payer's prior authorization decision, nor do our final rules require reprocessing claims submitted to previous payers. If payers believe that sending these data will be confusing for patients, they should include information in their educational resources that makes clear what the data exchange is and is not used for.
                    </P>
                    <HD SOURCE="HD3">ii. Data Retention</HD>
                    <P>In the proposed rule, we noted that our proposals would not impact any payer's data retention requirements. Specifically, we did not propose to require impacted payers to maintain data for unenrolled patients any longer or differently than they do today under current law, regulation, or policy. We understand that if a patient is uninsured or moves to a payer not subject to this regulation that does not request information from the previous payer, after a period of time, the previous payer may discard information, which would make it unavailable to the patient or other payers in the future.</P>
                    <P>We acknowledged that imposing requirements that would require payers to alter their data retention policies based on the actions of other payers would be a significant burden that would outweigh the benefits of such a policy. We considered proposing a minimum period during which a payer must maintain patient records after disenrollment, such as 1 or 2 years. However, we stated that most payers have policies in place that would maintain patient data for at least that long, and thus, such a requirement would be unnecessary and duplicative. We requested comment on whether our understanding is correct and whether there is a benefit to considering a data retention requirement in the future.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported our decision not to propose or establish a data retention requirement for patient records that would be different or longer than that required by current laws, regulations, and policies. Other commenters recommended that CMS set a minimum data retention timeframe. A commenter suggested that a payer should have to retain data until they are requested by a subsequent payer or after a minimum period of years, whichever occurs first. Other commenters recommended data be maintained for 5 or 10 years after a patient is unenrolled. Some commenters requested further guidance regarding the time for which impacted payers should maintain the data received from previous/concurrent payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not believe that additional data retention requirements are necessary at this time, as we do not wish to change or create conflict with existing rules. For example, under 42 CFR 422.504(d), 438.3(u), and 457.1201(q), MA organizations, Medicaid managed care plans, and CHIP managed care entities, respectively, must retain records for at least 10 years. Similarly, most states require 5-10 years of data retention. Nothing in this final rule would extend existing data retention requirements or create an obligation for perpetual maintenance. We emphasize that once a payer receives patient data from another payer, it becomes part of the patient's record and should be treated the same as data in the patient record created by the current payer. There should be no difference for data retention or data availability, as well as the same obligation to update or correct the data. The only difference is that payers may attach provenance information designating where the data originated.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that a patient's previous payer should not be required to respond to requests from the patient's current payer more than 90 days after the patient has disenrolled from the previous payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree with setting a 90-day limit on the initiation of a payer to payer data exchange by a patient's new payer. Patients should have access to their data for a significantly longer period than that. Some patients may not learn about payer to payer exchange for more than 90 days after the start of coverage. Others may move to payers that are not subject to this rule and do not have a Payer-to-Payer API or become uninsured for a period before moving back to an impacted payer. However, we do expect that a significant majority of the payer to payer data exchanges will be near the beginning of a patients' new coverage, particularly if the required patient educational resources clearly present the option at or shortly after enrollment. Impacted payers are required to exchange the data they maintain on a patient, with a date of service within 5 years of the request. We note that we discuss the timeframe for data retention in this section, for which we are not changing any regulation or requirement. We may consider, in future rulemaking, establishing a time period for the data to be available via Payer-to-Payer API, but such a timeframe would likely be a matter of years, not days or months.
                    </P>
                    <HD SOURCE="HD3">g. Patient Education Resources</HD>
                    <P>
                        Consistent with our proposals for the Provider Access API, we proposed that impacted payers (excluding including Medicaid managed care plans and CHIP managed care entities) would be required to provide patients with educational resources in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of the Payer-to-Payer API data exchange, patients' ability to opt in or withdraw their permission, and instructions for doing so. We proposed that state Medicaid and CHIP programs would provide this information to beneficiaries to be consistent with our proposal that states would be responsible for collecting beneficiaries' permission for payer to payer exchange. We proposed that those impacted payers would be required to provide these educational resources to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed previously, currently enrolled patients must be given the opportunity to opt into the payer to payer data exchange and to provide previous/concurrent payer information before the API compliance dates. We proposed that impacted payers would be required to provide these educational resources to those currently enrolled patients at or before requesting their opt in as well. In addition, we proposed that similar resources would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. Impacted payers would also be required to post these resources in an easily accessible location on the payer's public website. We requested comment on whether it would reduce payers' burden to only be required to provide these resources annually to any patients who have not opted in and those with known concurrent payers.
                        <PRTPAGE P="8848"/>
                    </P>
                    <P>Because we are finalizing a modification to our proposal and establishing Payer-to-Payer API compliance dates in 2027 this requirement to provide educational resources is also being moved from the proposed 2026.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposed requirements related to resources to educate patients about the benefits of data exchange between payers, the patient's right to opt in and to withdraw their permission, and instructions for doing so. Multiple commenters supported CMS's proposals to require that patient educational resources be in non-technical, simple, and easy to understand language. A commenter noted health literacy is the single largest barrier to health care access for those with coverage. A commenter recommended that CMS amend the patient resources requirements to require impacted payers to write resources at the fourth to sixth grade reading level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are slightly modifying the final regulation text to require that this information be provided in “plain language” instead of using the longer, more cumbersome phrase “non-technical, simple, and easy-to-understand language.” This modification does not change the meaning of the requirement that the educational information be non-technical and easy-to-use, but is intended to be more straightforward and to encourage impacted payers to follow the Federal Government's plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies use clear government communication that the public can understand and use. That statute applies only to Federal Government agencies, but we believe that the plain writing guidance developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We also encourage payers to review and utilize the health literacy resources that the AHRQ makes available on their website.
                        <SU>86</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             Agency for Healthcare Research and Quality (2023, May). Patient Education and Engagement. Retrieved from 
                            <E T="03">https://www.ahrq.gov/health-literacy/patient-education/index.html.</E>
                        </P>
                    </FTNT>
                    <P>We do not believe that it is prudent to establish a specific “grade level” requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how it is used. Furthermore, edits that are done to make text score at a lower grade level can produce choppy text that lacks cohesion.</P>
                    <P>However, we do note that 45 CFR part 92 requires impacted payers (such as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS develop resources, such as standardized language, tools, and delivery models, that payers could customize to ensure a consistent message to patients on what will be a confusing and complicated topic. A commenter noted that if CMS led the development, then the educational resources and programs for the Payer-to-Payer API could be standardized across carriers, FFS program administrators, and enrollment administrators to support consistent messaging and improve engagement with the API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In an effort to assist payers in meeting these requirements, we intend to provide templates or outlines for educational resources after this final rule is published and in time for payers to review and use prior to the compliance dates. However, we do not expect those resources to be fully sufficient to meet the requirements of this rule without additional content and customization by payers to include their specific processes for patients to opt in or withdraw their permission. To the extent possible, we encourage payers to collaborate on standardized resources to ensure consistent messaging to patients, regardless of the payer with whom they are enrolled. However, we also expect each payer to have to customize their resources with their own information and opt in process.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that it would benefit both patients and providers for us to allow third parties, such as an HIE or HIN, to provide educational resources to patients on the payer's behalf. The commenter stated that if multiple payers use the same third-party resources, it could simplify the solution across the industry.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Nothing in this rule will prevent a payer from working with a third party to develop the educational resources discussed here or from using subcontractors or downstream entities to the extent that program-specific laws permit that. As discussed in this section, payers may use an HIE or HIN to facilitate the Payer-to-Payer API exchange. However, we encourage payers to make it clear that any resources disseminated to patients under this requirement are from the payer. Patients are unlikely to devote attention to resources they receive from entities with which they are not familiar. While we expect that patients would recognize the name, logo, and other markings of official correspondence from their payer, they are unlikely to recognize their payer's partners. Therefore, while a third party may develop (and send on the payer's behalf) the required educational resources, we strongly recommend that these resources be clearly branded as communications from the patient's payer.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters highlighted the need to educate patients specifically on the opt in framework. Specifically, these commenters encouraged CMS to ensure that those educational resources are easy for patients to find. Some commenters recommended including that information in the patient's enrollment resources, while others disagreed and believe that that information may be easily missed within the larger quantity of information. A commenter recommended that in addition to payers, Federal agencies should play a role in patient education regarding data sharing. Another commenter recommended that CMS engage in testing patient education and opt in notifications before the compliance dates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that it is particularly important for patients to understand what they are opting in to. The educational information should highlight the benefits of API-based data exchange and explain patients' permission rights. Additionally, we emphasize that that information should be communicated in a way that is conspicuous and makes clear to patients that this policy provides them rights as consumers. However, each payer has different processes and modalities for communicating with patients and we do not want to be prescriptive in a way that may add unintended and unnecessary burden to payers.
                    </P>
                    <P>
                        As stated previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize using plain language for patients. In addition, we have stated that Medicare FFS intends to conform to the requirements of this rule, which includes patient educational resources. Beyond that, we will consider what role CMS may play in patient education. However, we know that 
                        <PRTPAGE P="8849"/>
                        patients have a relationship with their payers and expect to receive various communications from their payer relating to their coverage. Therefore, patients are more likely to consider educational resources that come directly from their payer. Further, these educational resources will need to include instructions for how patients can opt into Payer-to-Payer API data exchange and withdraw their permission; such instructions will need to be tailored to the specific procedures for each payer. While additional education from Federal agencies may supplement information from payers, it is not a substitute.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS limit the dissemination of annual Payer-to-Payer API educational resources to only those patients who have not opted in and those with known concurrent payers. A commenter recommended that making patient educational resources available on a payer's website should be sufficient and CMS should not require payers to send that information on an annual basis.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we understand that there may be additional burden to send all patients educational resources annually, we believe that such a requirement is necessary. As discussed previously, in section II.C.3.c.iv. of this final rule, patients must have the opportunity to withdraw their permission for payer to payer exchange at any time. While we generally expect exchange between a previous and new payer to be a one-time transaction, we do allow for the possibility of additional data exchanges, as discussed in section II.C.3.d.ii. of this final rule. Therefore, the opportunity to withdraw permission needs to be offered to all patients at any time. In order to be aware of this right, patients need to be informed of it. Payers are already required to send information to patients annually and including information about payer to payer data exchange should not be a significant burden to include with those resources. We do not believe that it would serve patients to have resources and information about the Payer-to-Payer API data exchanges and the patients' rights to opt into and out of those data exchanges available only on a payer's website. That would require patients to affirmatively seek out that information on their own, or to stumble across it by chance.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters encouraged CMS to use community outreach and education campaigns to encourage patients to opt into sharing their data via the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We will look into opportunities to educate patients on opting into data sharing. As mentioned previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize patient comprehension. Beyond that, we will consider what role CMS may play in patient education.
                    </P>
                    <HD SOURCE="HD3">4. Payer to Payer Data Exchange in Medicaid and CHIP</HD>
                    <HD SOURCE="HD3">a. Inclusion of Medicaid and CHIP Fee-for-Service</HD>
                    <P>As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76267), we did not require state Medicaid and CHIP FFS programs to comply with the payer to payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR 25568).</P>
                    <P>We proposed to make the payer to payer data exchange policies in this rule applicable to state Medicaid and CHIP FFS programs. We stated that requiring state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange in this rule would not be as burdensome as the non-API-based payer to payer data exchange that was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524), which we are now rescinding. That is because this new API would be leveraging the same data and technical standards as the Patient Access API. State programs should have already implemented Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this new API more manageable. Additionally, in the proposed rule we discussed the various benefits that the Payer-to-Payer API could produce for state Medicaid and CHIP programs, including creating efficiencies, reducing burden, and improving health outcomes (87 FR 76276).</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters supported applying the proposed requirements to Medicaid and CHIP FFS and agreed that such a policy would benefit Medicaid and CHIP beneficiaries who are covered by FFS by improving care coordination and continuity of care. Other commenters stated that the Payer-to-Payer API would reduce burden on patients and providers and allow state Medicaid agencies to operate more efficiently.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for including state Medicaid and CHIP FFS as impacted payers and are finalizing that proposal.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter questioned the expected value of the Payer-to-Payer API to state Medicaid agencies and the return on investment for the time and effort to implement systems.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Data exchange from one payer to another as patients transition between payers is a powerful way to support care coordination and continuity of care during coverage transitions, particularly in the Medicaid program where patients often churn in and out of the program and between payers. Electronic data exchange between payers would support payer operations and a patient's coverage transition to a new payer efficiently and accurately.
                    </P>
                    <HD SOURCE="HD3">b. Medicaid and CHIP—Seeking Permission Using an Opt In Approach in the Payer-to-Payer API</HD>
                    <P>We proposed that state Medicaid and CHIP agencies, like other impacted payers, establish a process to allow beneficiaries to opt into the payer to payer data exchange. We stated that an opt in framework means that the beneficiary or their personal representative would need to affirmatively permit state Medicaid and CHIP agencies to share their data, and without first obtaining that permission, the agency could not engage in the payer to payer data exchange for that beneficiary. In contrast, we proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the beneficiary and provider. Specifically, our policy to only require the Provider Access API data exchange with enrolled Medicaid and CHIP providers and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the Medicaid or CHIP agency that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship but would be exchanging data based on a patient's separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role and be required to provide affirmative permission for the Payer-to-Payer API data exchange.</P>
                    <P>
                        We proposed that state Medicaid and CHIP agencies, rather than their managed care plans or managed care entities, would be responsible for obtaining the required permission. We also proposed that the requirement to identify patients' previous/concurrent payers would apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For clarity and consistency with existing Medicaid and CHIP rules, we also 
                        <PRTPAGE P="8850"/>
                        proposed that a patient's permission would not be necessary to exchange data between a state Medicaid or CHIP agency and its contracted managed care plans or entities.
                    </P>
                    <P>We explained in the proposed rule that the opportunity for newly enrolling patients to opt in could take place through a single streamlined application, or at some later point of contact with the beneficiary prior to enrollment, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary's coverage.</P>
                    <P>We sought comments, specifically from states and contracted managed care plans and entities, how we could establish standards for patient data exchange for state Medicaid and CHIP agencies and their contracted managed care plans and entities without creating additional barriers or burden. We requested comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan or entity and the feasibility of sending patient permission during the enrollment process.</P>
                    <P>We considered proposing that the Payer-to-Payer API requirements would not apply for beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP agency and its contracted Medicaid or CHIP (as applicable) managed care plan or entity for the reasons outlined previously. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care programs. We requested comments on whether there are other ways we can ensure patient data are exchanged in this case in a manner that would reduce burden on states.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS reexamine whether its interpretation of 42 CFR 431.306(d) and 457.1110(b) would prohibit Medicaid agencies from participating in HIEs. A commenter encouraged CMS to explain whether requirements at 42 CFR 431.306(d) and 457.1110(b) prohibits Medicaid and CHIP programs from sharing beneficiary information with HIEs for the purposes of the Payer-to-Payer API. The commenters advocated for CMS to make a change to privacy regulations to support an opt out model consistent with industry standards. Multiple commenters that agreed with the proposal specifically recommended that state Medicaid and CHIP agencies leverage current solutions by HIEs and HINs to implement the proposed opt in requirement.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7) of the Social Security Act (the Act), which our regulations at 42 CFR part 431, subpart F, implement, requires that a state's Medicaid plan provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants' and beneficiaries' information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIPs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to implement and maintain the required Payer-to-Payer API would be directly related to the administration of the state plan because sharing beneficiary data through the Payer-to-Payer API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). States that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and new payers support opportunities for improved care coordination, reduce time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, or another payer. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency's capability for effective administration of the program.
                    </P>
                    <P>The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source to disclose that applicant's or beneficiary's data safeguarded under 42 CFR 431.305. State Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the agency has contracted to support the administration of its Medicaid or CHIP state plan. Such contractors would not be considered “outside sources” because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan. Thus, if a Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state's Medicaid or CHIP program, including implementing and maintaining the required Payer-to-Payer API, the HIE would not be considered an “outside source” and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for purposes directly connected to administration of the state plan without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b), respectively. Regardless, whether a Medicaid or CHIP agency contracts with an HIE to develop and maintain the required Payer-to-Payer API, the Medicaid or CHIP agency is responsible for ensuring the contracted entity implements a Payer-to-Payer API that meets all regulatory requirements, which includes that an individual or their representative has provided permission (opted in) prior to their information being shared with other payers via the Payer-to-Payer API.</P>
                    <P>In addition, to receive beneficiaries' information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid and CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency's contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations at 42 CFR part 431, subpart F), including but not limited to:</P>
                    <P>• Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and</P>
                    <P>
                        • Not disclosing data to an outside source, such as non-Medicaid or non-CHIP payers with whom the HIE might exchange data, without prior permission from the individual in accordance with 42 CFR 431.306(d).
                        <PRTPAGE P="8851"/>
                    </P>
                    <P>We did not propose any changes to Medicaid or CHIP confidentiality regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b), but we appreciate the comment and will consider it for any future rulemaking.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that an opt in process implemented within its system would not authorize another payer (particularly payers not subject to this regulation) to release patient information to the commenter or for the commenter to release a patient's data to a patient's subsequent payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         All data received, maintained, used, or shared via this proposed Payer-to-Payer API must be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations. As discussed previously, our regulation for Medicaid at 42 CFR 431.306 (incorporated via cross reference for CHIP at 42 CFR 457.1110(b)) sets forth certain requirements for release of Medicaid and CHIP applicant and beneficiary data. Consistent with our proposal, we are finalizing that when another payer (including a payer not subject to this final rule) is requesting a former Medicaid or CHIP beneficiary's information from the state Medicaid or CHIP agency, an attestation from a requesting payer that the patient or their representative has opted into data exchange with the requesting payer (that is, given permission for the Medicaid or CHIP agency to share the beneficiary's data) is sufficient to meet the requirements at 42 CFR 431.306 and 457.111(b) to allow the state Medicaid or CHIP agency to respond to the data request, though such permission must be received prior to the state Medicaid or CHIP agency sharing any beneficiary data. For more information about how the HIPAA Privacy Rule interacts with Payer-to-Payer API, see section II.C.3.c.iv.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters agreed with the proposal for state Medicaid and CHIP agencies to collect and manage patient decisions to opt into the payer to payer data exchange when beneficiaries are enrolled in Medicaid or CHIP managed care. Multiple commenters agreed that collecting a beneficiary's choice to opt into the payer to payer data exchanges as part of existing Medicaid and CHIP eligibility and enrollment processes would be the most effective and technically feasible approach for most states operating managed care programs in Medicaid and CHIP and would streamline the process for beneficiaries.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         For many reasons, we agree that the state Medicaid or CHIP program is the appropriate custodian of the patient's permission record, rather than the particular managed care plan or managed care entity through which a patient receives Medicaid or CHIP covered services. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state's Medicaid or CHIP program. Despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the Medicaid or CHIP managed care plans or entities with which they contract. Thus, a Medicaid or CHIP beneficiary's opt into the payer to payer data exchange, should be obtained by the state and will apply regardless of the delivery system in which the beneficiary is enrolled. Furthermore, we understand that in many states, managed care plans may not have any contact with beneficiaries prior to their enrollment in the Medicaid managed care plan or CHIP managed care entity.
                    </P>
                    <P>We believe the ideal time to allow patients to opt into the payer to payer data exchange is during their application for Medicaid or CHIP. As stated previously, obtaining a patient's opt in permission and identifying the previous/concurrent payer(s) cannot delay an applicant's eligibility determination or start of coverage. If a state has all the information necessary to determine an individual's eligibility before it obtains the individual's permission for the payer to payer data exchange, the state must determine the individual's eligibility and enroll the individual in Medicaid or CHIP coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment.</P>
                    <P>Because we expect higher rates of patients to opt in when they are presented with the option at a point when they are already providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in Medicaid or CHIP rather than expecting patients to opt in through a separate process.</P>
                    <P>We are finalizing our proposal to require the state to establish a process for obtaining opt into the payer to payer data exchange prior to the state Medicaid or CHIP agency's Payer-to-Payer API compliance dates, and prior to the enrollment of new beneficiaries after that date, and that the state Medicaid and CHIP agencies will be responsible for obtaining the required permission.</P>
                    <P>To the extent that doing so is consistent with Federal Medicaid and CHIP requirements, including those at section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and applied to separate CHIPs through a cross reference at 42 CFR 457.1110(b), Medicaid and CHIP agencies are welcome to contract with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that Medicaid or CHIP agencies' systems do not. Nothing in this rule would prohibit a Medicaid or CHIP agency from partnering with an HIE to meet its requirements, but Medicaid and CHIP agencies must continue to comply with all other Federal requirements applicable to the operation of Medicaid and CHIP.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concerns about state Medicaid and CHIP agencies' resources to collect and manage patient decisions to opt into the exchange of their data via the Payer-to-Payer API. A commenter stated that it may need to build separate functionality to support implementation of the opt in requirement if it is unable to support the requirement within the state's existing eligibility system. A commenter noted that it will require significant work to implement an opt in process in states and territories where the Medicaid agency does not complete eligibility and enrollment processes and recommended that CMS ensure an appropriate implementation timeline in these instances. A commenter suggested that CMS work with states to implement a consistent solution to avoid inconsistencies in what data are collected and how to address the concern about resources. Another commenter specifically expressed that the process to identify a previous/concurrent payer would be challenging for Medicaid.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand and appreciate that state Medicaid and CHIP agencies will need to create new processes to request a patient's permission to exchange data and identifying information about their previous/concurrent payer(s), and then to share that information with their managed care plans and managed care entities. States have different eligibility and enrollment processes, and a one-size-fits all approach may not be optimal. We are not being prescriptive on this process, as we want each program to implement the requirements in the least burdensome, most efficient way for them.
                    </P>
                    <P>
                        We also understand that making changes to applications can be a significant administrative process, and 
                        <PRTPAGE P="8852"/>
                        for states where Medicaid or CHIP eligibility is determined by a state or regional agency other than the Medicaid or CHIP agency, there will be additional administrative steps to implementation. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide adequate time for payers to implement these requirements. Further, there may be other places where a state could obtain a patient's data exchange permission for the Payer-to-Payer API data exchange. For instance, a state could leverage an online portal or app, if beneficiaries frequently use those pathways for other purposes, such as reporting a change in circumstance or providing information for eligibility renewal. However, the option should be equally available for all beneficiaries and if only a small portion of the Medicaid or CHIP population uses these tools to communicate with the Medicaid or CHIP agency, that subset would be self-selected for greater technology literacy and taking this approach could exacerbate inequality.
                    </P>
                    <P>We note that the single streamlined application, which for Medicaid and CHIP purposes is described at 42 CFR 435.907(b)(1) and 457.330, respectively, and is also used for applications through the FFEs, includes questions about concurrent coverage information. We also expect that some states that do not use the single streamlined application already ask for this information for Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally make sense to gather permission for payer to payer data exchange at the point the state collects concurrent payer information. We note that the patient permission provisions in this rule will apply only to the payer to payer data exchange discussed here and would not affect states' ability to perform Coordination of Benefits or Third-Party Liability activities as they do today.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that CMS should ensure that regulatory language clearly makes the opt in requirement applicable to Medicaid managed care plans.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We intentionally did not include regulatory text requiring Medicaid managed care plans and CHIP managed care entities to meet the requirement to collect patient permission for payer to payer data exchange. As discussed in section II.C.4.b. of this final rule, we are finalizing that requirement for state Medicaid and CHIP agencies because we believe that they are the proper entity to hold a patient's opt in decision. State Medicaid and CHIP agencies may work with their managed care plans and entities to gather that information, but ultimately the requirement to gather and maintain that information is the responsibility of the state Medicaid or CHIP agency. As proposed and discussed in section II.E.2.a. of this final rule, we are finalizing that the responsibility to collect patient permission for the Payer-to-Payer API data exchange is not eligible for exemption from the API requirements. Therefore, even if a state receives an exemption from the Payer-to-Payer API, it is still responsible for collecting and maintaining a record of patient opt in permission for this data exchange. We note that we are also finalizing that state Medicaid and CHIP programs, rather than their managed care organizations, are responsible for providing educational resources at the time of requesting permission for payer to payer data exchange and for collecting identifying information about patients' previous/concurrent payer(s).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested clarification on whether a patient's opt in permission is required to share data between impacted payers within the same state Medicaid program. Another commenter asked us to explain what types of managed care plans are included in this statement (for example, MCOs, PIHPs, PAHPs, Primary Care Case Managers (PCCMs), integrated plans for patients dually eligible for Medicare and Medicaid).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As we explained in the preamble to the proposed rule (87 FR 76238), we know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans and entities. We do not intend the opt in requirements for the Payer-to-Payer API to interfere with or affect this permissible exchange. Medicaid managed care plans, and CHIP managed care entities are not outside sources as described at 42 CFR 431.306(d), but are part of a state's Medicaid and/or CHIP programs as a whole, because these entities are contracted to support the agency's administration of its Medicaid or CHIP state plan. Specifically, Medicaid managed care plans and CHIP managed care entities are contracted with the Medicaid state agency to deliver Medicaid program health care services to beneficiaries under the state plan.
                    </P>
                    <P>Hence, we are finalizing our proposal that if a Medicaid or CHIP agency is exchanging information per our Payer-to-Payer API proposals with a managed care plan or managed care entity with which they have a contract, the requirement to obtain patient opt in would not apply. We consider any plan and entity that has a contract with the state Medicaid or CHIP agency to deliver Medicaid program health care services to beneficiaries under the state plan, including state Medicaid agency contracts with D-SNPs under 42 CFR 422.107, to be part of the state's Medicaid or CHIP programs, regardless of the coverage model. We note that this policy and opt in requirement to share data between impacted payers would not replace regulatory requirements as described at 42 CFR part 422, including as they relate to integrated D-SNPs.</P>
                    <P>We note that permissible data exchange only covers data that facilitate that plan's contracted services. For instance, it would be inappropriate to share patient data with a managed care plan or entity other than the one with which the patient is enrolled. The other Payer-to-Payer API requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply to data exchange required in this final rule between state Medicaid and CHIP agencies and their managed care plans or managed care entities. The exchange must also not be prohibited by other law.</P>
                    <HD SOURCE="HD3">c. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of Payer to Payer Data Exchange</HD>
                    <P>In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the payer to payer data exchange (this was also addressed in the proposed rule at 87 FR 76278).</P>
                    <HD SOURCE="HD3">d. Medicaid Expansion CHIP</HD>
                    <P>In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 86 FR 76279).</P>
                    <HD SOURCE="HD3">5. Extensions, Exemptions, and Exceptions</HD>
                    <P>See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Payer-to-Payer API for state Medicaid and CHIP FFS programs and exceptions for the Payer-to-Payer API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 86 FR 76279).</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8853"/>
                        <GID>ER08FE24.003</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8854"/>
                        <GID>ER08FE24.004</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <PRTPAGE P="8855"/>
                    <HD SOURCE="HD3">6. Final Action</HD>
                    <P>After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:</P>
                    <P>• Impacted payers must implement and maintain a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.</P>
                    <P>• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Payer-to-Payer API.</P>
                    <P>• The data exchange between a previous payer and a new payer is limited to data with a date of service within the previous 5 years.</P>
                    <P>• Impacted payers are required to request patients' permission for payer to payer data exchange and identifying information about patients' previous/concurrent payers no later than 1 week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment.</P>
                    <P>See further discussion for the exact details of the final requirements for impacted payers.</P>
                    <P>We are finalizing the rescission of the payer to payer data exchange policy previously finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1).</P>
                    <P>We are finalizing a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Payer-to-Payer API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR R4 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1).</P>
                    <P>We are also finalizing a requirement that, by the deadlines, impacted payers (except Medicaid managed care plans and CHIP managed care entities) must establish and maintain a process to gather patient permission for payer to payer data exchange no later than 1 week after the start of coverage. We are finalizing an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. Impacted payers must also have a process for patients to change their permission at any time.</P>
                    <P>We are finalizing a requirement that, by the deadlines, impacted payers must establish and maintain a process to identify a patient's previous/concurrent payer(s) no later than 1 week after the start of coverage. As part of this process, impacted payers are required to allow a patient to report multiple previous/concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers are required to request that patient's data from all previous/concurrent payers. If a patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to engage with the enrollee to collect this information.</P>
                    <P>We are also finalizing a requirement that, no later than the compliance dates, impacted payers must establish and maintain a process to gather permission and previous/concurrent payer(s) information from patients who are already enrolled.</P>
                    <P>We are finalizing a requirement that, by the deadlines, impacted payers must request a patient's data from a patient's previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in. Impacted payers must also request data from a patient's previous/concurrent payers(s) within 1 week of that patient's request to do so. Impacted payers must include an attestation with this request for data affirming that the patient is enrolled with the requesting payer and has opted into the data exchange in a manner that meets the legal requirements.</P>
                    <P>Additionally, we are finalizing a requirement that, by the deadlines, when an impacted payer has sufficient identifying information and the patient has opted in, they must request data from any concurrent payers at least quarterly. Impacted payers who receive a request for a patient's data from a known concurrent payer must respond with the required data within 1 business day of receiving the request.</P>
                    <P>We are finalizing a requirement that, by the deadlines, upon receiving a request that meets the legal requirements, impacted payers must make any of the required information that they maintain available to new payers no later than 1 business day after receiving the request.</P>
                    <P>We are finalizing a requirement that, by the deadlines, impacted payers must make available via the Payer-to-Payer API, by request from payer that meets certain requirements, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorization requests and decisions (excluding those for drugs and those that were denied) that the payer maintains with a date of service within 5 years of the request. The required information is—</P>
                    <P>• The prior authorization status;</P>
                    <P>• The date the prior authorization was approved;</P>
                    <P>• The date or circumstance under which the prior authorization ends;</P>
                    <P>• The items and services approved; and</P>
                    <P>• Structured and unstructured administrative and clinical documentation submitted by a provider.</P>
                    <P>We are finalizing a requirement that impacted payers are required to make this information about prior authorizations available for the duration that the authorization is active and for at least 1 year after the prior authorization's last status change.</P>
                    <P>We are finalizing a requirement that, by the deadlines, information received by an impacted payer through the payer to payer data exchange must be incorporated into the payer's patient record.</P>
                    <P>We are finalizing a requirement that, by the deadlines, impacted payers (except Medicaid managed care plans and CHIP managed care entities) must provide educational resources to their patients about the Payer-to-Payer API in plain language. These resources must include information about the benefits of Payer-to-Payer API data exchange, the patient's ability to opt in or withdraw that permission, and instructions for doing so. Impacted payers must make this information available to patients when requesting the opt in decision. Thereafter, impacted payers must provide this information to patients annually, in mechanisms the payer ordinarily uses to communicate with patients. These resources must also be available in an easily accessible location on payers' public websites.</P>
                    <P>
                        These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding NEMT PAHPs), and QHP 
                        <PRTPAGE P="8856"/>
                        issuers on the FFEs at the CFR sections listed in Table D1.
                    </P>
                    <HD SOURCE="HD3">7. Statutory Authorities for Payer to Payer Data Exchange Proposals</HD>
                    <P>We note that we received no public comments on the statutory authorities for our Payer-to-Payer API policies.</P>
                    <HD SOURCE="HD3">a. MA Organizations</HD>
                    <P>For MA organizations, we are finalizing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act to adopt by regulation standards consistent with and to carry out Part C of Title XVIII of the Act (such as section 1852(d)(1)(A) of the Act). In addition, section 1857(e)(1) of the Act authorizes the Secretary to adopt contract terms and conditions for MA organizations that are necessary, appropriate, and not inconsistent with the statute. In total, the regulations we are adopting in this final rule for MA organizations and MA plans are necessary and appropriate because they address and facilitate continued access to enrollees' medical records and health information when they change payers, which will support consistent and appropriate coordination of coverage when enrollees have concurrent payers and will support coordination of care and continuation of active courses of treatment when enrollees change payers.</P>
                    <P>
                        In regulations establishing the MA program,
                        <SU>87</SU>
                        <FTREF/>
                         CMS described it as a program designed to: provide for private plan options available to Medicare beneficiaries, especially those in rural areas, enrich the range of benefit choices, provide incentives to plans and add specialized plans to coordinate and manage care in ways that comprehensively serve those with complex and disabling diseases and conditions, use competition to improve service and benefits, invest in preventive care, hold costs down in ways that attract enrollees, and advance the goal of improving quality and increasing efficiency in the overall health care system. This final rule supports these goals and enables the MA program to advance services for its enrollees by providing greater access to information in a way that will improve care management for payers, providers, and the patient.
                    </P>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             Medicare Program: Establishment of the Medicare Advantage Program, 70 FR 4588 (January 28, 2005) (to be codified at 42 CFR part 417).
                        </P>
                    </FTNT>
                    <P>Section 1856(b) of the Act requires the Secretary to establish regulatory standards for MA organizations and plans that are consistent with, and carry out, Part C of the Medicare statute, Title XVIII of the Act. The Payer-to-Payer API proposals support MA organizations sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions, with another payer that, as identified by the enrollee, has or does cover the enrollee. Such exchanges of data about patients could facilitate continuity of care and enhance care coordination. As discussed for the Provider Access API in section II.B. of this final rule, allowing payers to share health information for one or more patients at once could increase efficiency and simplicity of administration. Though we are not requiring payers to share data for more than one patient at a time, there are efficiencies to doing so, both for communicating information and for leveraging available technology.</P>
                    <P>Further, providing MA organizations with additional data about their enrollees through these data exchanges will increase the scope of data that the MA organizations must make available to enrollees through the Patient Access API. It will give payers access to all their enrollees' information with limited effort and enable the payer to then make that information available to providers and to enrollees through the Provider Access and Patient Access APIs. It may reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which may introduce efficiencies and improve care. As discussed earlier, if a new payer receives information and documentation about prior authorization requests from a previous payer, the new payer can review this information and determine that a new prior authorization may not be necessary for an item or service that was previously approved. Instead, the same care may be continued, reducing burden on both payers and providers, and improving patient care. While the statutory provisions governing the MA program do not explicitly address sharing data with other payers that cover or have covered an enrollee, the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies necessary and appropriate for the MA program. Further, requiring use of the API and the specifications for the data to be shared provides a step toward greater interoperability among payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive patient information in a timely manner, which could lead to more appropriate service utilization and higher patient satisfaction. Such goals are consistent with the MA statute.</P>
                    <P>Section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information as far as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Currently, consumers across public and private sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real-time. Thus, we to align our standards with current demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The information exchanged via the Payer-to-Payer API will ultimately be accessible to enrollees via the Patient Access API and will therefore improve timeliness to medical records and health information as enrollees will no longer have to spend time contacting previous payers to access their information. These data will be accessible as needed by the enrollee's current payer and would therefore support timely access.</P>
                    <P>Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with section 1852(d)(1)(A) of the Act, the final requirement here for MA organizations to implement and maintain a Payer-to-Payer API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under this final rule, the data received from other impacted payers will become part of the data the MA organization maintains and will therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this final rule; the data could then be used for treatment and coordination of care purposes.</P>
                    <P>
                        The finalized policies in this rule are necessary, appropriate, and consistent 
                        <PRTPAGE P="8857"/>
                        with Part C of Title XVIII of the Act. Overall, establishing these regulatory requirements for MA organizations will improve enrollee's quality of care by ensuring that they do not lose their patient records when they change payers.
                    </P>
                    <HD SOURCE="HD3">b. Medicaid and Children's Health Insurance Program</HD>
                    <P>Our provisions in this section fall generally under our authority in the following provisions of the Act.</P>
                    <P>• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan.</P>
                    <P>• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.</P>
                    <P>• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.</P>
                    <P>The final requirements related to the Payer-to-Payer API are authorized by sections 1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, we anticipate that it will help state Medicaid programs improve the efficiencies and simplicity of their own operations under a Medicaid state plan, consistent with sections 1902(a)(4) and (a)(19) of the Act. It will give Medicaid agencies and their managed care plans access to their beneficiaries' information in a standardized manner and enable states to then make that information available to providers and patients through the Patient Access and Provider Access APIs. It may also reduce the amount of time needed to evaluate a patient's current care plan and have possible implications for care continuity, which may introduce efficiencies and improve care. Receiving patient information at the start of coverage will lead to more appropriate service utilization and higher beneficiary satisfaction by Medicaid agencies and those managed care plans considered impacted payers under this final rule by supporting efficient care coordination and continuity of care, which could lead to better health outcomes.</P>
                    <P>As discussed in section II.C.3.b. of this final rule, when a state Medicaid program has access to a previous payer's prior authorization decisions, the Medicaid program may choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage.</P>
                    <P>
                        Our final rule is expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries' best interests, consistent with sections 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid beneficiaries experience coverage changes and churn in a given year.
                        <SU>88</SU>
                        <FTREF/>
                         Therefore, exchanging this information with a beneficiary's next payer may also better support care continuity for Medicaid beneficiaries. When states share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, they can support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who might churn into and out of Medicaid coverage. The final rule may also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers can be identified and provided case management services, reduce duplication of services, and improve the coordination of care, as appropriate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             Churning occurs when people lose Medicaid coverage and then re-enroll within a short period of time. Medicaid beneficiaries frequently experience churning. 
                            <E T="03">See</E>
                             U.S. Department of Health and Human Services, Assistant Secretary for Planning and Evaluation (2021, April 12). 
                            <E T="03">Medicaid churning and continuity of care: Evidence and policy considerations before and after the COVID-19 pandemic</E>
                             (issued April 12, 2021). Available at: 
                            <E T="03">https://aspe.hhs.gov/reports/medicaid-churning-continuity-care.</E>
                        </P>
                    </FTNT>
                    <P>In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306.</P>
                    <P>Requiring the data described in this section to be shared via the Payer-to-Payer API is consistent with states' requirements to provide safeguards meeting certain requirements to share these data since it is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). As described previously in sections II.A.5.b. and II.B.6.b. of this final rule related to authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, may support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who churn into and out of Medicaid coverage, described in more detail previously. When state Medicaid agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the requirements of 42 CFR part 431, subpart F, including 42 CFR 431.306.</P>
                    <P>
                        For Medicaid managed care, and in addition to the general authorities cited previously regarding Medicaid programs, the finalized exchange of adjudicated claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer will greatly enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations under 42 CFR 438.208(b), which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and 
                        <PRTPAGE P="8858"/>
                        social support providers; make a best effort to conduct an initial screening of each enrollee's needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee's needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API in this final rule will give managed care plans the information needed to perform these required functions much more easily, thus enhancing the effectiveness of the care coordination, and helping enrollees receive the most appropriate care in an effective and timely manner.
                    </P>
                    <P>For CHIP, we finalized these requirements under our authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. The provisions in this final rule can strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to our beneficiaries.</P>
                    <P>As with the Medicaid FFS and Medicaid managed care programs, the provisions in this section of the final rule for CHIP FFS and CHIP managed care entities require using a Payer-to-Payer API to exchange claims, encounter, clinical and prior authorization data at a beneficiary's request, or any time a beneficiary changes payers, using a FHIR API. The current payer can use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this final rule, a new payer will have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients will enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they will have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, or other possibly relevant encounters that could help payers manage their care. This final rule is consistent with the goal of providing more informed and effective care coordination, which will help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act.</P>
                    <P>Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP agencies' data exchange through the Payer-to-Payer API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.</P>
                    <HD SOURCE="HD3">c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>For QHP issuers on the FFEs, we finalized these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.</P>
                    <P>Requiring QHP issuers on the FFEs to implement and maintain a Payer-to-Payer API will allow the seamless flow from payer to payer of adjudicated claims, and encounter data, all data classes and data elements included in a standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations, that are maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Ensuring a means for an enrollee's new issuer to electronically obtain the enrollee's claims, encounter, and other data, as well as prior authorization information with corresponding medical records, from the previous issuer will reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests.</P>
                    <P>We believe that it is in the interest of qualified individuals that QHP issuers on the FFEs have systems in place to send information important to care coordination to a departing enrollee's new payer, and that QHP issuers on FFEs also have systems in place to receive such information from other payers on behalf of new and concurrent enrollees, as appropriate and consistent with the provisions in this section. Having patient information at the beginning of a new plan may assist the new payer in identifying patients who need care management services, which could reduce the cost of care. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.</P>
                    <P>Though we are not requiring the exchange of all enrollees' data at one time between impacted payers, we encourage QHP issuers on the FFEs to use the Bulk Data Access IG for the Payer-to-Payer API once it is available, as it will improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. The opportunity to support the exchange of data from multiple patient records at once, rather than data for one patient at a time, may be cost effective for the issuers.</P>
                    <HD SOURCE="HD2">D. Prior Authorization API and Improving Prior Authorization Processes</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>This section of the final rule addresses the topic of prior authorization and includes both technical and operational requirements intended to improve the prior authorization process for payers, providers, and patients. Here, we finalize our proposals for payers to implement and maintain an API to support and streamline prior authorization processes; respond to prior authorization requests within certain timeframes; provide a specific reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals.</P>
                    <P>
                        In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286) we provided a comprehensive review of the work HHS conducted regarding prior authorization processes and their associated burden to identify the primary issues that needed to be addressed to alleviate the burdens of these processes on patients, providers, and payers. We cited studies from ONC 
                        <SU>89</SU>
                        <FTREF/>
                         which highlighted the burdens associated with prior authorization including difficulty determining payer-specific requirements for items and services that require prior authorization; inefficient use of provider and staff time processing prior authorization requests and information (sending and receiving) through fax, telephone, and web portals; 
                        <PRTPAGE P="8859"/>
                        and unpredictable wait times to receive payer decisions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             Office of the National Coordinator for Health Information Technology (2020). Strategy on Reducing Burden Relating to the Use of Health IT and EHRs. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.</E>
                        </P>
                    </FTNT>
                    <P>
                        We referenced American Medical Association (AMA) physician surveys from 2018, 2020, and 2022 
                        <SU>90</SU>
                        <FTREF/>
                         which noted issues with prior authorization, and we used these studies to estimate the costs and savings for this final rule. Please see the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286-76287) for the detailed context of these industry surveys as well as the reports from the 2019 meetings of the two Federal advisory committees, the Health Information Technology Advisory Committee (HITAC) 
                        <SU>91</SU>
                        <FTREF/>
                         and the National Committee on Vital and Health Statistics (NCVHS),
                        <SU>92</SU>
                        <FTREF/>
                         which conducted joint hearings to discuss persistent challenges with prior authorization workflows and standards; and the follow up 2020 task force on the Intersection of Clinical and Administrative Data (ICAD) Task Force at 87 FR 76287.
                    </P>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             American Medical Association (2022). AMA prior authorization (PA) physician survey. Retrieved from 
                            <E T="03">https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             Office of the National Coordinator for Health Information Technology (2023). Health Information Technology Advisory Committee (HITAC). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/federal-advisory-committees/health-information-technology-advisory-committee-hitac-history.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             National Committee on Vital and Health Statistics (2022). Charter. Retrieved from 
                            <E T="03">https://ncvhs.hhs.gov/about/charter/.</E>
                        </P>
                    </FTNT>
                    <P>We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing certain covered items and services to receive payment for delivering those items or services to a covered individual. As we stated in the CMS Interoperability and Prior Authorization proposed rule, prior authorization has an important place in the health care system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Interested parties, including payers and providers, say that dissimilar payer policies, inconsistent use of electronic standards, and other technical barriers have created provider workflow challenges and an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and can create a health risk for patients if inefficiencies in the process cause delays in medically necessary care. The prior authorization policies in this final rule apply to any formal decision-making process through which impacted payers render an approval or denial determination in response to prior authorization requests based on the payer's coverage guidelines and policies before services or items are rendered or provided.</P>
                    <P>As discussed in section I.D. of this final rule, we exclude drugs from the provisions in this section, meaning any drugs that could be covered by the impacted payers affected by these provisions. Thus, the policies herein do not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs that may be covered by an impacted payer. We include a definition of drugs for purposes of this exclusion for each impacted payer in the CFR where applicable to provisions for implementation of the Prior Authorization API. For MA organizations, the definition of drugs also includes any products that constitute a Part D drug, as defined by 42 CFR 423.100, and are covered under the Medicare Part D benefit by MA-PDs; this part of the definition specific to MA organizations provides a clear dividing line for MA-PD plans that must comply with this new rule. However, payers may voluntarily incorporate their business rules for prior authorizations for drugs using the Prior Authorization API now being finalized in this rule.</P>
                    <P>As noted in section I.D., although Medicare FFS is not directly affected by this final rule, we will evaluate opportunities to improve automation of prior authorization processes in the Medicare FFS program as feasible.</P>
                    <P>We received nearly 900 letters in response to the CMS Interoperability and Prior Authorization proposed rule, with hundreds of individual comments specific to the importance of the topic of prior authorization and the critical timing of addressing this issue. Most of the comments were relevant to the proposals and others were out of scope. The majority of commenters supported our proposals which are intended to mitigate longstanding issues with prior authorization processes and many commenters stressed the importance of finalizing the policies in this final rule as soon as practicable to resolve patient access to care issues. Some commenters identified concerns with the timing of compliance for the policies (too soon or too late), with prior authorization decision timeframes (too short or too long), and with reporting of metrics (too little or too much). We carefully reviewed each comment and considered the input to inform the policies now being described in this final rule. To be fully responsive to the public comment process, yet avoid creating an overwhelming final rule, we have consolidated input from all of the comments and summarized the contents with our responses for each provision. We value the diverse commentary provided by all interested parties as the volume and scope helped shape our approach to these final policies which advance our commitment to interoperability, burden reduction, process improvement for prior authorization, and transparent rulemaking. Comments that were out of scope for this final rule are not addressed here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that, while prior authorizations may improve the safety or efficiency of care in some circumstances, they can lead to negative effects for patients and providers. A commenter suggested that CMS implement a broader set of changes to prior authorization processes to correct current abuses, specifically noting that improving the speed of prior authorizations without addressing the content of prior authorization requests will not improve outcomes of inappropriate use of prior authorizations. Another commenter recommended that CMS further evaluate prior authorization burdens and make additional proposals.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate that there are still concerns about the general use of prior authorization in the health care system. However, prior authorization continues to have a place in the health care system and can support functions such as utilization management, cost-effective care delivery, patient safety, and preventing unnecessary treatment. The policies we are finalizing in this rule are intended to improve the transparency and efficiency of the process.
                    </P>
                    <P>
                        Regarding suggestions for us to implement broader policy changes for prior authorization, we acknowledge that Federal policies alone cannot control all payer specific processes or patient health outcomes. Policies must be applied with good medical judgment and review, and we reiterate that we, in the administration of its programs 
                        <SU>93</SU>
                        <FTREF/>
                         and implementation of programmatic authority, continue to evaluate opportunities for future rulemaking to alleviate burdens, mitigate harm, and improve patient care. For example, in the CY 2024 MA and Part D final rule (88 FR 22120), we finalized several provisions to ensure that utilization management tools, including prior authorization requirements, are used in ways that ensure timely and appropriate access to medically necessary care for 
                        <PRTPAGE P="8860"/>
                        beneficiaries enrolled in MA plans.
                        <SU>94</SU>
                        <FTREF/>
                         Specifically, we explained current rules related to acceptable coverage criteria for basic benefits that require MA organizations to comply with national coverage determinations (NCDs), local coverage determinations (LCDs), and general coverage and benefit conditions included in Traditional Medicare regulations. In addition, under new regulations adopted in that final rule, when coverage criteria are not fully established, MA organizations may create internal coverage criteria based on current evidence in widely used treatment guidelines or clinical literature made publicly available to us, enrollees, and providers. The CY 2024 MA and Part D final rule also streamlines prior authorization requirements, including adding continuity of care requirements and reducing disruptions for beneficiaries. First, we finalized that prior authorization policies for coordinated care plans may only be used to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations and/or ensure that an item or service is medically necessary based on standards specified in that final rule (see 42 CFR 422.138(b)). Second, we finalized that for MA coordinated care plans,
                        <SU>95</SU>
                        <FTREF/>
                         an approval granted through prior authorization processes must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient's medical history, and the treating provider's recommendation, and that plans provide a minimum 90-day transition period when an enrollee who is currently undergoing an active course of treatment switches to a new MA plan or is new to MA (see 42 CFR 422.112(b)(8)). Finally, to ensure prior authorization and other utilization management policies are consistent with CMS rules, we finalized a requirement that all MA plans that use utilization management policies must establish a Utilization Management Committee to review all utilization management policies, including prior authorization, annually and ensure they are consistent with regulatory standards for MA plan coverage, including compliance with current, Traditional Medicare's NCDs and LCDs (see 42 CFR 422.137).
                    </P>
                    <FTNT>
                        <P>
                            <SU>93</SU>
                             CMS's oversight and administration authority and roles for MA, Medicaid, CHIP, and the FFEs vary with each program.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>94</SU>
                             National Archives (2022, December 27). 
                            <E T="04">Federal Register</E>
                            . Retrieved from 
                            <E T="03">https://www.federalregister.gov/documents/2022/12/27/2022-26956/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             An MA coordinated care plan is a plan that includes a network of providers that are under contract or arrangement with the organization to deliver the benefit package approved by CMS; this includes MA plans that are HMOs, PPOs, and MA plans for special needs individuals.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. Compliance Dates</HD>
                    <P>We proposed compliance dates for most impacted payers in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). There was one exception for some of the Medicaid FFS fair hearing and notice requirements, as discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76299 and 76300), which would take effect upon the effective date of this final rule.</P>
                    <P>Based on commenter feedback, we are extending the compliance dates for the Prior Authorization API for all impacted payers consistent with the compliance dates for the Provider Access and Payer-to-Payer APIs to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers. The prior authorization business process improvements, or those provisions that do not require API development or enhancement, including the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics are being finalized as proposed with a compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2026” for the various payers.</P>
                    <P>We received comments on the compliance dates for both the Prior Authorization API and process improvement proposals that do not require API development or enhancement. Overall compliance timeline comments are addressed in greater detail in section I.B. of this final rule. In this section, we discuss comments more specifically related to the Prior Authorization API and process improvement policies.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS require the shortened prior authorization decision timeframes earlier than 2026, with some noting that payers, specifically MA organizations, already have the technological capability to implement these new decision timeframes in 2024. These commenters did not provide additional context for the reference to technological capabilities. Other commenters recommended that CMS should require compliance with all requirements that are not contingent on implementation of the Prior Authorization API by January 2025 (for example, decision timeframes, providing specific denial reasons, and reporting of metrics). Commenters said payers should not have trouble adapting their processes to meet the requirements related to decision timeframes and communication with patients and providers by that date, and that patients and providers should not have to wait any longer to benefit from the proposals in this rule. Other commenters cited reasons for implementing the Prior Authorization API proposal as soon as possible or in 2024 or 2025, such as to ensure that bidirectional flow of electronic prior authorization information is fully operational by January 1, 2026 and to protect patients from delays in, and restricted access to, cancer care.
                    </P>
                    <P>Other commenters indicated that transitioning to use the API-facilitated process for prior authorization will require significant development and implementation efforts. A commenter explained that developers would need 12 to 18 months following publication of the final rule to design, develop, test, and release updated software. The commenter went on to state that payers would likely need this same amount of time following publication of the final rule to build their specific coverage and prior authorization criteria and rules into the system for each of their impacted health plans for the Prior Authorization API. This commenter explained that providers and payers will also need time to work together to reconcile variances in the FHIR implementations to ensure that they can engage in accurate exchange of prior authorization information.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the comments in support of the proposed compliance dates in 2026 for the business process improvement provisions of the CMS Interoperability and Prior Authorization proposed rule that do not require API development or 
                        <PRTPAGE P="8861"/>
                        enhancement, specifically the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics. We are finalizing those compliance dates for those new requirements in this final rule. We agree that those prior authorization process improvements will initiate burden reductions and support both payers and providers.
                    </P>
                    <P>
                        Although there are several early implementations and pilots of the Prior Authorization API in place today, it is important to take into account the capabilities of all payer types and sizes to implement the requirements of the Prior Authorization API, including internal resource allocation for implementation and testing. All payers must identify relevant prior authorization coverage criteria and rules and program these criteria and rules into the appropriate format for the API in accordance with the IG. Subsequent programming and testing for the questionnaires within the API must take place to ensure functionality. To accommodate these development efforts, CMS is finalizing 2027 compliance dates for the Prior Authorization API. The compliance timeframe should enable the industry to establish a strong technical framework to support the development and scalability of the API-based solution. We anticipate that this timeframe will provide more time for development and testing to enable the integration of the Prior Authorization API between payers, providers, and EHR developers. Additional time for the API implementation also supports state efforts to process the extraordinarily high volume of renewals and other eligibility and enrollment actions that need to be conducted following the end of the Medicaid continuous enrollment condition at section 6008(b)(3) of the Families First Coronavirus Response Act (FFCRA),
                        <SU>96</SU>
                        <FTREF/>
                         which has consumed both staff and technical resources.
                    </P>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             As described in prior CMS guidance, states have up to 12 months to initiate, and 14 months to complete, a renewal for all individuals enrolled in Medicaid, CHIP, and the Basic Health Program (BHP) following the end of the Medicaid continuous enrollment condition that ended on March 31, 2023—this process has commonly been referred to as the “unwinding period.” For more details 
                            <E T="03">see</E>
                             CMS (2023, January 27). State Health Official letter #23-002. Retrieved from 
                            <E T="03">https://www.medicaid.gov/sites/default/files/2023-08/sho23002.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Requirement Tto Implement an API for Prior Authorization</HD>
                    <HD SOURCE="HD3">a. Prior Authorization API</HD>
                    <P>To help address prior authorization process challenges and continue our roadmap to interoperability, we proposed that certain payers implement and maintain a PARDD API to be used by providers to facilitate the prior authorization process. As we explained in section I.B. of this final rule, for consistency with the naming conventions of the other APIs, we have elected to finalize the name of this API to the Prior Authorization API rather than the PARDD API. The purpose of the API is to support the full prior authorization process, as described in the CMS Interoperability and Prior Authorization proposed rule. We believe this revised name best reflects that purpose in this final rule.</P>
                    <P>In this section, we are finalizing policies to improve the prior authorization process between payers and providers using a Prior Authorization API. The purpose of the API is to streamline the process and ensure that payers use technology to provide more useful information about when and how to obtain a prior authorization and the status of an approved or denied prior authorization.</P>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we discussed the anticipated benefits of the Prior Authorization API and explained how this API would automate certain tasks, thereby mitigating some of the obstacles of the existing process. We stated that the API would allow a provider to query the payer's system to determine whether prior authorization was required for certain items and services and identify documentation requirements. The Prior Authorization API would send the prior authorization request from the provider's EHR or practice management system to the payer. In this final rule, we are finalizing the requirement to use certain standards and making recommendations to use certain IGs to support development of the FHIR API. Use of the Prior Authorization API will enable automation for the prior authorization request and response within the clinical workflow of the provider. The IGs and relevant standards, which are discussed in section II.G. of this final rule, serve as the instructional manuals for the functional capability of the API. When operational, the API enables a provider to submit a request about a medical item or service, determine if additional information is required, submit that information, and additionally assemble the necessary information to submit a prior authorization request. The response from the payer must indicate whether the payer approves (and for how long) or denies the prior authorization request or requests more information from the provider to support the request.</P>
                    <P>
                        To support the implementation and maintenance of the Prior Authorization API, we are requiring certain standards and recommending certain IGs, as discussed elsewhere and in section II.G. of this final rule. With the publication of the HTI-1 final rule (89 FR 1192), our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. of this final rule and reflected throughout this final rule. For the Prior Authorization API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Prior Authorization API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.
                        <SU>97</SU>
                        <FTREF/>
                         We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the CRD IG STU 2.0.1, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG STU 2.0.0, and PAS IG STU 2.0.1. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposal to require impacted payers to implement and maintain a Prior Authorization API to improve automation of the prior authorization process. Many commenters stated that the API has the potential to support the needed transition to electronic prior authorization. Commenters also stated that the Prior Authorization API would 
                        <PRTPAGE P="8862"/>
                        reduce the burden for providers and speed up the prior authorization process for patients to improve care and access treatment options. A commenter stated that the API would offer much-needed transparency for rural providers around the prior authorization process. Other commenters stated that the API would potentially replace old ways of conducting the prior authorization process and give way to new ways of conducting prior authorization and explained that the prior authorization provisions laid out in the CMS Interoperability and Prior Authorization proposed rule could provide a good return on investment for payers. Multiple commenters supported CMS's efforts to implement a standardized API that makes payers' prior authorization and other documentation requirements electronically accessible to providers and that supports a more streamlined prior authorization request and response process. Multiple commenters believe this change will offer many benefits for patients and providers, including increasing access to care for patients and increasing providers' understanding of prior authorization requirements by providing upfront information about which services require prior authorization and what type of documentation is required to support approval of a prior authorization request; and increasing automation in the submission, receipt, and processing of requests, which could support more timely responses. Commenters also stated that this automation will help decrease administrative costs and that the Prior Authorization API would improve the efficiency of providing services to patients due to the request and response being automated and in real-time, as well as the quality of patient care. A large group of commenters expressed their support for the proposed requirement for payers to implement the Prior Authorization API because it will make their physical therapy businesses more efficient and allow them to focus on treating patients.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that these policies will serve to mitigate some of the burdens that exist in the prior authorization process today. This is the reason we are finalizing a modification to the compliance dates. Our proposal did not include a requirement for the Prior Authorization API to provide real-time processing of the prior authorization request, but we agree that incorporating a level of automation and facilitating electronic prior authorization processing could improve processing timelines in the future. Though we anticipate that some of the responses or decisions potentially may be made in real-time, other decisions will continue to necessitate review and evaluation by clinical staff. The complete automation of a complex process such as prior authorization is an ongoing process of continuous improvement.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times. A commenter stated that the amount of data to be transmitted and used by payers and providers through the API is burdensome and impractical. This commenter wrote that the continued transmission of medical information from non-FHIR systems (for example, administrative transactions) will require payers to translate such information into a format that is useable for the Prior Authorization API, which would only shift the manual prior authorization burden, not alleviate it. The commenter stated it is important to maintain industry flexibility around prior authorization to continue industry innovation in interactive decision-making processes with providers to ensure the best care experience possible for patients. Multiple commenters expressed concern that the required implementation of the Prior Authorization API might increase the burden for both providers and payers. A commenter expressed concerns that what time may be saved through the API may end up being redirected to maintain the API, field questions from patients and providers, and support external development when requests are incomplete, which may even require a dedicated team to answer provider questions throughout the electronic prior authorization lifecycle. This commenter provided insight into their experience with their current online portal and provider submissions of prior authorizations, and continued reliance on electronic faxes. A commenter expressed concerns that the maintenance of the API will also place significant burdens on payers to translate all coverage criteria to questions suitable for the electronic prior authorization process and to keep such information up to date. Another commenter also stated that the work involved in identifying all policies and authorization processes that would be included in the Prior Authorization API will be a significant effort as it will require significant resources, staff, and time.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge concerns about the new technology and processes associated with the Prior Authorization API, including implementation challenges, potential conflicts with existing workflows, and increased workload for initially implementing the Prior Authorization API. Payers will need to identify the policies, conduct the analysis, and do the necessary programming for the next few years. Providers will also experience an initial implementation and data collection burden associated with translating records into FHIR-compatible formats. It is in part based on these considerations that we decided to modify our proposed compliance dates so that the impacted payers and providers alike will have sufficient time to conduct testing on the newly structured prior authorization process. We disagree with commenters who indicated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times, and with those who were concerned that the transmission of medical information from systems would shift the prior authorization burden to manual processes rather than alleviate it. The benefits of using an electronic prior authorization process improve the manual and burdensome process used today. Making the prior authorization process electronic will reduce the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. Once the Prior Authorization API is in place and a provider can connect to a payer's system using that API, the manual effort for both payers and providers should decrease because clinical and administrative staff will be able to leverage the technology to conduct a more streamlined process for submitting prior authorization requests. Payers should be able to shift resources to review the requests more efficiently. While payers may have their policies documented, these are not in any standard formats, nor are they readable in any structured way. Providers must often download documents from different portals and then interpret them individually. The API will centralize and automate this process for both payers and providers. Further, we have included several significant policies that do not require API development or enhancement in this final rule, one of which relates to shortening the deadline by which impacted payers must respond to prior authorization requests from providers. The policies being finalized in this rule have been developed over time with input from providers, payers, and patients to address the technical 
                        <PRTPAGE P="8863"/>
                        and operational issues described to us as the most significant issues in the prior authorization process.
                    </P>
                    <HD SOURCE="HD3">b. FHIR Implementation Guides</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we proposed to require the use of certain technical specifications (that is, IGs adopted as implementation standards) adopted at 45 CFR 170.215 (87 FR 76239). We also proposed that the same documentation requirements and discontinuation and denial of access standards as we proposed for the Patient Access API (discussed in section II.A.2. of this rule), the Provider Access API (discussed in section II.B.2. of this rule), and the Payer-to-Payer API (discussed in section II.C.3. of this rule) would apply to the Prior Authorization API. Additionally, for the Prior Authorization API, we specifically recommended using certain FHIR IGs that have been developed to support the functionality of the Prior Authorization API. These IGs are as follows:</P>
                    <FP SOURCE="FP-1">• The CRD IG</FP>
                    <FP SOURCE="FP-1">• The DTR IG</FP>
                    <FP SOURCE="FP-1">• The PAS IG</FP>
                    <P>These three IGs are designed to be used by the payer, or implementer, to develop and implement the Prior Authorization API. The IGs undergo regular development and testing to support implementation and use of the Prior Authorization API and to improve the API's functionality in support of an improved prior authorization process. Technical information and website access are provided in section II.G. of this final rule.</P>
                    <P>
                        The first IG recommended for use to develop the Prior Authorization API is the CRD IG. As described on the HL7 web page, the CRD IG defines a workflow to allow payers to provide information about coverage requirements to providers through their clinical systems.
                        <SU>98</SU>
                        <FTREF/>
                         Use of this IG improves the transparency of specific coverage rules specific to the patient and the provider based on the payer's prior authorization policies, and, when implemented, provides decision support to providers when they are ordering services. This is the first stage of the process for determining whether authorization is required for certain items or services. The CRD IG provides the functionality to enable the API to inform the provider if a prior authorization is required, and information about the payers' prior authorization coverage rules, so the provider knows what information is necessary to support a request. The functionality of the CRD may return a decision to the provider if there is sufficient information and the payer supports early determinations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             Health Level Seven International (2024, January 8). Da Vinci—Coverage Requirements Discovery. Retrieved from 
                            <E T="03">https://www.hl7.org/fhir/us/davinci-crd/.</E>
                        </P>
                    </FTNT>
                    <P>
                        The second IG recommended for use by payers to develop the Prior Authorization API is the DTR IG. On the HL7 IG web page, the description explains how this IG specifies how payer rules can be executed in a provider context to ensure that documentation requirements are met.
                        <SU>99</SU>
                        <FTREF/>
                         This IG is a companion to the CRD IG. Its purpose is to automate the process of assembling documentation to support a prior authorization request for a specific payer. The instructions will allow the provider to download questionnaires and populate them automatically with information from the EHR or other systems for the completion of documentation requirements needed to demonstrate medical necessity for a proposed item or service, based on payer rules. The DTR IG enables the return of completed templates with specific FHIR resources identified as required to support the medical necessity of the service or item that is being requested for a prior authorization. This process replaces the need to manually request, gather, and submit documentation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             Health Level Seven International (2023, November 7). Da Vinci—Documentation Templates and Rules. Retrieved from 
                            <E T="03">https://www.hl7.org/fhir/us/davinci-dtr/.</E>
                        </P>
                    </FTNT>
                    <P>
                        The third IG recommended for the Prior Authorization API is the PAS IG. On the HL7 web page, the description explains that the PAS IG enables direct transmission of prior authorization requests (and can request/receive immediate authorization) from within EHR systems using the FHIR standard and that it can create the mapping between FHIR and HIPAA compliant X12 transactions.
                        <SU>100</SU>
                        <FTREF/>
                         The PAS IG ensures that the API takes the information from the CRD and DTR and allows provider systems to send (and payer systems to receive) requests using FHIR. Providers and payers can still meet separate regulatory requirements, where required, to use the X12 278 transaction standard for prior authorization(s) to transport the prior authorization request and response. The PAS IG is the basis for: (1) assembling the information necessary to substantiate the clinical need for a particular treatment; and (2) submitting the assembled information and prior authorization request to an intermediary before it is sent to the intended recipient. As these IGs have been expanded and improved, the workgroup has enhanced the graphic display depicting the workflow and made it available on the HL7 website.
                        <SU>101</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             Health Level Seven International (2023, December 1). Da Vinci—Documentation Templates and Rules. Retrieved from 
                            <E T="03">https://www.hl7.org/fhir/us/davinci-pas/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             Health Level Seven International (2023, November 20). Da Vinci Coverage Requirements: Technical Background. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/davinci-crd/background.html.</E>
                        </P>
                    </FTNT>
                    <P>Most importantly, use of the instructions from the IG and the API provides the necessary information about the status of the prior authorization request—the response indicates whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or requests more information from the provider to support the prior authorization request. The PAS IG also defines capabilities around the management of prior authorization requests, including checking on the status of a previously submitted request, revising a previously submitted request, and canceling a request. Section II.G. of this final rule provides additional discussion of both the required and recommended standards and IGs to support the Prior Authorization API.</P>
                    <P>Comments regarding requiring versus recommending the IGs, maturity of the IGs, and technical implementation challenges are addressed in section II.G. of this final rule. For example, commenters recommended that the FHIR IGs should be required rather than recommended, as merely recommending the IGs would lead to an additional burden for both payers and providers as they may use varied implementations of the required APIs that would ultimately reduce interoperability. We also received multiple comments about technical implementation challenges and the maturity of the recommended IGs. Technical comments such as these are addressed in section II.G. Here we respond to the comments specific to the standards and IGs for implementation of the Prior Authorization API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS and HL7 ensure the recommended CRD, DTR, and PAS IGs are fully tested before the effective date of the final rule, as the IGs have not been adequately or widely tested in real-time clinical settings. The commenter noted that these IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter cautioned that the IGs have several data elements and processes that are optional, which means payers could meet decision requirements with vague responses, 
                        <PRTPAGE P="8864"/>
                        hence jeopardizing CMS's prior authorization reform goal. Multiple commenters supported using the PAS IG and stated that the IG is well-positioned to support the development of the proposed Prior Authorization API. A commenter noted that many of the proposed requirements are covered in the PAS IG STU 2.0.0, which is targeted for publication in calendar year 2023. The commenter continued by stating that based on functional requirements, additional updates can be made to the IG to ensure it fully supports the proposed Prior Authorization API once finalized in preparation for compliance in 2026. However, other commenters expressed some concerns about recommending these IGs. Multiple commenters noted that hospitals and insurers may need to use more than one technology solution to participate and track activity using the Prior Authorization API. A commenter expressed concern with the proposed IGs, which seem to require fast responses, within 5 seconds, and encouraged CMS to monitor technical standards as they are developed to avoid excessive burdens that the agency did not intend to create.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         CMS is recommending the three IGs to implement the Prior Authorization API. These IGs, the CRD, DTR, and PAS IGs, were created to be used together to provide implementation flexibility. Several optional or “situational” elements were included in these guides as a means to connect them in a single workflow while allowing for the decoupling of these processes where necessary. For example, the CRD IG might be used to develop an API specific to prior authorization coverage requirements, and a separate API, linked to that one, built using the DTR IG. Some hospitals and providers will need more than one technology solution to connect to the payer's Prior Authorization API endpoint based on the architectures and systems of the provider organization. Impacted payers and providers may have separate and unconnected systems that address coverage and eligibility, documentation, and prior authorization. Since publication of the CMS Interoperability and Prior Authorization proposed rule, updated versions of the CRD, DTR, and PAS IGs have all been published. We refer readers to Table H3 for the required standards and recommended IGs to support API implementation.
                    </P>
                    <P>In response to the specific comment about implementation strategies, we refer implementers to the HL7 Da Vinci workgroups for technical guidance; however, we understand that payers may need to pull multiple technology solutions together to meet the overall Prior Authorization API requirements. Concerning the response time of 5 seconds, which is near real-time, we anticipate that most systems can accommodate this communication exchange when the information is available. The PAS IG has a recommended synchronous response time of 15 seconds. Instructions are available in the IG for how systems should respond in a timeframe with the best possible information. For further technical details, we encourage interested parties to reach out to the appropriate HL7 workgroups.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that there are potential technological challenges for the implementation of the Prior Authorization API. A commenter noted that the proposed rule does not specify what technology hospitals need to support or implement the API, nor what technology is needed to track participation or be required to participate in the API once finalized. This commenter noted that providers will be using the Prior Authorization API without any meaningful testing. Another commenter noted that they currently offer providers an option to submit electronic prior authorizations through an online portal, but utilization is low as most providers still favor fax as their preferred method to send prior authorizations, and portal prior authorizations often require corrections to incorrect data entries.
                    </P>
                    <P>Multiple commenters said CMS should do more to support the implementation of the Prior Authorization API. A commenter supported regulatory efforts to require payers to build APIs to automate prior authorization, but questioned whether the CMS Interoperability and Prior Authorization proposed rule goes far enough to accomplish that goal. Another commenter noted that the Prior Authorization API will require payers, providers, and vendors to connect but noted that multiple infrastructure challenges will have to be resolved to ensure API implementation success and cited the work of the HL7 FAST Accelerator to identify and address scalability issues to avoid duplication of efforts, including security and authentication.</P>
                    <P>
                        <E T="03">Response:</E>
                         The regulations we are finalizing in this rule require impacted payers to implement a Prior Authorization API, and providers are encouraged to use the technology in their CEHRT to take advantage of the improvements in prior authorization processes that will be available through use of the Prior Authorization API. As we noted in the proposed rule, HL7 launched an implementation division in 2021, specifically to provide support for implementers, including education and technical support. This division will provide payers, providers, and vendors with access to information about the types of technology and software that will address implementation, education, and testing of the standards, IGs, and APIs. Furthermore, the HL7 workgroups, which are open to the public, continue to be the best resources to learn about implementation. We will continue to work with associations, developers, and HL7 on identifying or supporting the development of appropriate resources for education.
                    </P>
                    <P>The HL7 FAST Accelerator is addressing the scalability issues of the FHIR standard through its work on security and the directory IGs. We and ONC participate in the HL7 FAST Accelerator and will monitor progress on the IGs being developed by that project.</P>
                    <P>The policies in this final rule are an important component of the overall CMS strategic plan to reduce burden, advance interoperability, and improve patient care. This rule finalizes significant changes to improve the patient experience and alleviate some of the administrative burden by applying policies which address both technical and process barriers. These policies represent foundational regulatory steps toward addressing the longstanding challenges of prior authorization.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter, writing from the provider perspective, stated that the Prior Authorization API would complicate clinical and administrative workflows by requiring some combination of staff time and additional technological advances and recommended the FHIR API be combined with the HIPAA transaction standard.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not agree that using the Prior Authorization API will complicate clinical work. Rather, time will be saved across all personnel tasks, including researching the requirements for prior authorization across multiple payers, entering information into systems, submitting requests, processing approvals, or determining next steps if a denial is received. The Prior Authorization API is capable of conducting the prior authorization request as a FHIR only data exchange, or in combination with the HIPAA transaction standard.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters urged CMS to name the CDex IG as one of the recommended IGs to use in support of the Prior Authorization API 
                        <PRTPAGE P="8865"/>
                        and stated that it is a critical part of burden reduction and plays an important role in supporting FHIR prior authorization transactions as proposed. To support the attachments for the Patient Access, Provider Access, and Payer-to-Payer APIs, as well as the supporting documentation requirements for the Prior Authorization API, this IG provides the instructions to enable the exchange of structured documents 
                        <SU>102</SU>
                        <FTREF/>
                        —meaning those which could be read and interpreted by a computer. This functionality to attach documents to support a prior authorization is currently missing from the other FHIR IGs and standards. A commenter stated that the PAS IG could support existing Federal and state requirements to exchange attachments if implementers also added the functionality of using the CDex IG. Use of this IG would further support efficiencies in the prior authorization process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             General comparison of structured versus unstructured documents: Structured documents are organized and fit into spreadsheets and relational databases. Structured documents often contain numbers and fit into columns and rows and are easily searchable. Examples are ICD-codes, Star Ratings, and other discrete data elements. Unstructured documents include traditional business files, word processing documents, presentations, notes, and PDFs.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response:</E>
                         We are aware that early adopters have begun testing with the CDex IG for attachments to advance additional use cases for the Prior Authorization API. This final rule does not address standards for attachments and does not prohibit using the CDex IG or other attachment standards.
                    </P>
                    <HD SOURCE="HD3">c. Implementation, Automation, and Other General Considerations for the Prior Authorization API and Processes</HD>
                    <P>We proposed and are finalizing requirements for impacted payers to implement a Prior Authorization API to improve the prior authorization process. The policy would require use of new standards for some impacted payers and some changes in procedures. We received comments on the use of new standards, technology, and automation with considerations for implementation and have grouped them here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that they support the proposed requirements for the Prior Authorization API; however, they believe much more needs to be done to achieve the CMS objectives for this policy. Multiple commenters shared potential concerns and challenges with the implementation of a Prior Authorization API. A commenter wrote that the Prior Authorization API use case will not work without provider participation, as the API requires bidirectional exchange between impacted payers and providers. A commenter expressed concern regarding the resource development needed for providers and noted this needs to be more widely understood before the implementation of the Prior Authorization API. The commenter recommended CMS work with interested parties to ensure practices can utilize and leverage this API. The commenter encouraged CMS to work with ONC to extend the applicability of the Prior Authorization API requirements to providers and EHR vendors to ensure technical readiness and enable greater adoption of the Prior Authorization API and electronic prior authorization. A commenter suggested that CMS require plans to provide to each contracted physician, upon request and regardless of their use of the API, the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service. The commenter noted that some physicians may not be able to adopt these systems by the compliance dates.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are finalizing compliance dates in 2027 for payers to implement the Prior Authorization API which should provide sufficient time for payers to implement the APIs, collaborate with EHR vendors to support appropriate connections for their providers, and develop outreach materials. Ongoing pilots demonstrate that payers and providers can implement the necessary infrastructure by those compliance dates. While providers are not required by this final rule to use the Prior Authorization API, in section II.F. of this final rule we are incentivizing providers to use this API by finalizing new electronic prior authorization measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote Prior Authorization API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are adding a new measure titled “Electronic Prior Authorization” under the HIE objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year (CY) 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. There could be many benefits for providers for improvements in the prior authorization process, and we encourage all providers to evaluate whether use of the Prior Authorization API could benefit their practices. Payers should also encourage providers in their network to use the Prior Authorization API, given that it could be timesaving for both parties, and we anticipate that many payers will begin education and awareness campaigns as more pilots are launched and/or payer APIs are readied for testing. We are monitoring the activities of existing pilots and receiving positive reports from participants. ONC may consider developing and making available additional criteria for EHR certification for electronic prior authorization in future rulemaking.
                    </P>
                    <P>
                        We did not propose to specifically require payers to make available the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service, but we did propose that when an impacted payer denies a prior authorization request, the payer must include a specific reason for that denial in a notice to the provider who requested the prior authorization. See section II.D.3. regarding that proposal and the final policy. While we do not oversee contract provisions between payers and providers, the CY 2024 MA and Part D final rule (88 FR 22120) 
                        <SU>103</SU>
                        <FTREF/>
                         finalized a new requirement at 42 CFR 422.101(b)(6) for MA plans to make certain information about their internal coverage policies publicly accessible, including a list of the evidence considered in developing the internal coverage criteria; that final rule also limits using internal coverage criteria for Part A and Part B benefits to when coverage criteria are not fully established in Medicare statute, regulation, NCD, or LCD. We anticipate this information, along with the requirement that MA plans provide a reason for denying a request for prior authorization (at 42 CFR 422.122 as adopted here and currently in existing 42 CFR 422.568(e)) will address the commenter's concern about access to clinical research and evidence supporting denials of coverage in the MA program. In addition, the CY 2024 MA and Part D final rule adopted a new regulation, at 42 CFR 422.137, that requires a Utilization Management Committee to annually review the policies and procedures for all utilization management, including prior 
                        <PRTPAGE P="8866"/>
                        authorization, used by the MA plan, and a new regulation at 42 CFR 422.138 that limits how prior authorization may be used by certain MA plans. Per 42 CFR 422.138, coordinated care MA plans (for example, Health Maintenance Organization [HMO], Preferred Provider Organization [PPO], and point-of-service [POS] plans) may only use prior authorization to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations for the specific item or service and to ensure that the requested item or service is medically necessary (for Part A and B benefits) or clinically appropriate (for supplemental benefits). Finally, we remind readers that MA regulations at 42 CFR 422.202(b) and 422.136(a) require MA organizations to provide education and outreach about utilization management policies and engage in consultation with contracted providers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             
                            <E T="03">See</E>
                             88 FR 22120 through 22345 (April 12, 2023). Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly. Retrieved from 
                            <E T="03">https://www.federalregister.gov/documents/2023/04/12/2023-07115/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters discussed automating prior authorizations, and many were in support of automation, providing technological suggestions for automation of the prior authorization process. A commenter stated that, for prior authorization forms, specific clinical questions require answer formats that are easily understood and automated by a computer. Another commenter described how payers might automate the prior authorization process by utilizing existing matrices to create algorithms that would be able to review a large proportion of their prior authorization requests. A commenter noted that deep learning AI methods for submitted clinical data could be used to inform the review and electronic prior authorization approval process to expedite a decision that simulates a consensus of expert human judgment.
                    </P>
                    <P>Multiple commenters recommended that CMS explore automating service “bundle” prior authorizations for instances where one episode of care needs multiple prior authorizations (for example, a knee replacement surgery), as this would help ease administrative burden and reduce delays in patient care.</P>
                    <P>
                        <E T="03">Response:</E>
                         We are closely following the level of interest in the types of automation that might be brought to bear on the prior authorization process, particularly around the infrastructure for communications, and the innovative thinking shared in the public comments. While CMS did not directly address using AI for purposes of implementing the prior authorization policies, or any provisions of this final rule, we encourage innovation that is secure; includes medical professional judgment for coverage decisions being considered; reduces unnecessary administrative burden for patients, providers, and payers; and involves oversight by an overarching governance structure for responsible use, including transparency, evaluation, and ongoing monitoring. We also reiterate that impacted payers must comply with Federal and state policies and the requirements of the standards and recommended IGs in implementing these APIs. We encourage these and other individuals to participate in the HL7 IG development groups to share these ideas with the drafters of the IGs to further refine their functionality.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS include additional requirements for payers. A commenter recommended that CMS require payers to offer their electronic prior authorization system at no cost to providers. Multiple commenters stated that health plans should be required to provide a web-based interface for providers and patients with a standardized, easy-to-use web page with an up-to-date database that quickly indicates whether prior authorization is required. The commenter stated that this web page should include prior authorization rules and medical policies. A commenter requested that the required response to the query on the online database include the following data points: transaction ID, group or member ID, date of service, prior authorization required, instructions, and a medical policy link. A commenter recommended that, in the case of a technical glitch with the prior authorization process, insurance plans should develop a backup system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not specifically address whether payers could charge providers for use of or access to the Prior Authorization API. We would encourage payers not to charge additional costs beyond those that may exist to conduct prior authorization business functions today, including the costs of conducting transactions. We do not anticipate that fees would be charged for use of the API or other services required by this final rule, but are aware that payers will be funding their own development and vendor related costs.
                    </P>
                    <P>Concerning the specific functionalities commenters requested be available through portals, online systems, or the API, such as easy-to-use web pages with an up-to-date database that quickly indicates whether prior authorization is required or what the medical policies are, we reiterate that payers are required to implement a Prior Authorization API that allows a provider to query a payer's system to determine whether a prior authorization is required, to identify documentation requirements, and to receive information about whether a specific prior authorization request has been approved or denied. As part of fulfilling these required functions, information about the policies and how they have been developed may be available, but we understand that the level of additional information and detail about the development of prior authorization and coverage policies could vary by payer. There may be other connected systems and resources available with information about the medical policies that are associated with the Prior Authorization API to which the provider will be able to refer to understand how decisions are being made for certain items and services. Furthermore, under existing Federal and state laws, such as the HIPAA Privacy and Security Rules, administrative, technical, and physical safeguards policies and procedures must be in place to ensure that systems have effective backup controls to protect access to patient data during planned and unplanned downtime. We would expect impacted payers to already have such procedures in place for reliable backup systems.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters noted that payers will have to digitize their prior authorization policies to meet the Prior Authorization API requirements, which will be difficult and time-consuming. Multiple commenters noted that payers may be concerned that if a significant amount of their providers do not adopt the new prior authorization API process, the payer will not receive the full benefit of their investment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that payers will have to digitize their prior authorization policies to meet the API requirements. Several organizations have implemented the Prior Authorization API as pilot projects or as part of the Da Vinci Exception Project, and we are aware that implementation of the API requires a significant investment of resources. We also recognize that the full benefit of the API will be achieved when providers use the API to request information about prior authorization requirements and change existing workflow patterns. The changes for both payers and providers will maximize the return on investment from the new electronic exchange. We encourage other impacted payers to engage with these early implementers to learn from their experience and to begin evaluating their policies to understand the level of effort that will be required within their organizations. To support 
                        <PRTPAGE P="8867"/>
                        the analysis, implementation, and testing, we are also finalizing compliance dates that are a year later than we proposed to provide additional time for the necessary work to implement the Prior Authorization API and to conduct outreach and education to the provider community.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS include a Prior Authorization API opt out policy and another commenter recommended that CMS explain providers' responsibilities related to communicating patients' right to opt out of the Prior Authorization API and their responsibility to notify the payer of that decision.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Prior authorization is an administrative process between a payer and provider that is conducted almost completely electronically today with no direct burden on the patient. We would anticipate that an individual who wishes to obtain medical services expediently might wish for their provider to use the most efficient resource available to them. The opt out/opt in rules that we are finalizing in this rule are for the Provider Access and Payer-to-Payer APIs' data exchange requirements, discussed in sections II.B. and II.C., and do not apply to the Prior Authorization API. While this final rule does require impacted payers to develop and implement the Prior Authorization API, this rule does not require providers to use the API. As discussed in section II.F., this final rule does include policies regarding using the Prior Authorization API for the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program. As many providers are currently conducting these processes through EHRs in the office, with the patient present, we would encourage providers to explain any activity to the patient, as is being done for any electronic transaction, including electronic prescribing, lab orders, and scheduling. We also anticipate that providers would want to use a process in which their EHR or other medical record systems are capable of connecting with the APIs and exchanging certain data and documents using FHIR standards. At a minimum, the Prior Authorization API will provide a means for providers to identify the prior authorization requirements for the impacted payers, which will save time and burden associated with having to research those requirements manually. We do not believe it is necessary to add a new opt out process for patients regarding prior authorization. These are administrative tasks already in place in provider offices. We reiterate that providers are not required by this rule to use the Prior Authorization API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters discussed prior authorization criteria and specifically referenced the CY 2024 MA and Part D final rule for the enhancements it provides for prior authorization requirements. A commenter requested that CMS require payers to make their prior authorization criteria public in advance of the publication of this final rule and to ensure that physicians with expertise in the services are involved in their development. Other commenters requested that CMS ensure that prior authorization criteria be peer-reviewed. A commenter wrote that the Prior Authorization API will increase transparency into payer prior authorization criteria, and another noted that using an electronic data exchange could improve the accuracy of prior authorization determinations. A few commenters wrote that the solution to prior authorizations must include both an expedited prior authorization process as well as appropriate clinical decision-making, particularly with treatment guidelines supported by clinical evidence. Another commenter stated that the Prior Authorization API could specifically speed up the process of prior authorization for key treatments of gynecologic cancers. Commenters noted that the increased transparency will include better timing for responses and accuracy for treatment protocols subject to prior authorization.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that if the API can enhance provider understanding of the requirements for requesting a prior authorization, a provider's ability to submit a complete and accurate request electronically will be improved and the manual intervention needed to collect additional information reduced. This transparency in requirements and criteria should improve communication between payers and providers during the prior authorization process, which is a core element of the functionality of the Prior Authorization API. We also appreciate comments suggesting that prior authorization criteria should be peer-reviewed and include appropriate clinical decision-making information with treatment guidelines that are supported by clinical evidence. Use of such clinical evidence is helpful to reviewers when creating care treatment plans and evaluating prior authorization requests. We have also heard from many payer organizations that aligning with clinical guidelines is part of their process when establishing prior authorization criteria and we encourage this practice for all payers. We did not make specific proposals related to developing prior authorization criteria, but acknowledge the value of such clinical involvement.
                    </P>
                    <P>We also note that the provisions in this final rule on prior authorization will work with several of the utilization management and prior authorization policies in the CY 2024 MA and Part D final rule to further CMS's overall goals of improving prior authorization processes to serve the needs of payers, providers, and patients. We encourage readers to review that rule as well (88 FR 22120) to have a greater understanding of the limits on how MA organizations may use and implement prior authorization.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters discussed the need for APIs to be integrated with EHR systems. A commenter expressed concern that current EHR systems will not be set up to accommodate the requirements of this rule. Another commenter noted that an obstacle to the effective implementation of the Prior Authorization API is the lack of standardized coding and structured data in provider EHRs to support adjudication of a prior authorization request. The commenter stated that it will be important for EHR clinical data to be standardized to successfully adjudicate prior authorization requests through API interfaces.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate comments about standardization and the need for providers and EHR system vendors to address consistency in the coding of medical records for interoperable data exchange. Such comments do not reflect a technical readiness issue for the Prior Authorization API or the standards but rather an industry readiness to meet the requirements to enable and automate prior authorization processes. Over the next few years, both provider management systems, as well as certified EHRs, will advance in their use of standards, data exchange, and connectivity. Implementation of a content standard at 42 CFR 170.213 (USCDI) for all data classes and data elements will support communication about medical records will reduce the variation in medical record coding, increase structured data, and support the ability for interoperable data exchange. The IGs that support the Prior Authorization API provide the framework for exchanging standard information between the payer and provider systems.
                    </P>
                    <P>
                        We note that ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization through an RFI titled “Electronic Prior Authorization Standards, 
                        <PRTPAGE P="8868"/>
                        Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022, issue of the 
                        <E T="04">Federal Register</E>
                        . The Unified Agenda, current at the time of this final rule's publication, includes an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955-AA06). The description indicates that this proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.
                        <SU>104</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             Office of Information and Regulatory Affairs, Office of Management and Budget, Executive Office of the President. Reginfo.gov. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that CMS work with states to resolve conflicts between this rule and existing state regulations. A commenter noted that Arizona has recently enacted legislation and published guidance establishing a uniform prior authorization request form. The commenter expressed concern that potentially conflicting policies would create confusion and operational process challenges for QHP issuers on the FFEs and providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are aware that many states are also attempting to improve prior authorization processes and have read the Arizona legislation HB 2621 from 2022 
                        <SU>105</SU>
                        <FTREF/>
                         regarding using standard paper forms and electronic portals. We do not believe there is a conflict between those requirements and this final rule as the Prior Authorization API required by this final rule can support the various state required standardized forms for electronic submission of the prior authorization request. The AMA also provides a list of other state legislation designed to improve prior authorization processes, many of which support or enhance the provisions in this final rule, for example, by supporting the establishment of an electronic prior authorization process.
                        <SU>106</SU>
                        <FTREF/>
                         Should a conflict present between state and Federal requirements, the general rule is that the regulated entity must comply with both requirements unless compliance with one makes compliance with the other impossible; in such a situation, Federal law generally preempts state law in the absence of statutory direction otherwise.
                    </P>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             Office of the Director Arizona Department of Insurance and Financial Institutions (2022, January 3). Regulatory Bulletin 2022-01(INS). Retrieved from 
                            <E T="03">https://difi.az.gov/sites/default/files/Prior%20Authorization%20Bulletin%20with%20forms%202022-01.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             American Medical Association (2022). 2022 Prior Authorization (PA) State Law Chart. Retrieved from 
                            <E T="03">https://fixpriorauth.org/sites/default/files/2022-12/2022%20Prior%20Authorization%20State%20Law%20Chart.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Implementation Timing Considerations</HD>
                    <P>In the proposed rule (87 FR 76290), we stated that we had considered proposing that the Prior Authorization API be implemented in a phased approach. However, we explained that we did not think a phased implementation strategy would reduce the burden on impacted payers or providers, but rather could increase burden during the initial implementation. We also explained that a phased approach could delay the availability of electronic prior authorization for certain items and services, which could in turn reduce the overall adoption of the Prior Authorization API by providers who do not see their specialties and services represented in the initial rollout of the available Prior Authorization API. We sought comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning in 2026. Additional comments and responses regarding the timing and deadlines for compliance with the Prior Authorization API and those policies that do not require API development or enhancement are discussed in sections I.B. and II.D.1.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters supported a phased implementation of the Prior Authorization API to allow impacted payers sufficient time to build the API and recommended processes that would use the IGs in a staggered fashion rather than implementing the entire process for prior authorizations. Other commenters recommended a phased implementation based on the following order for the IGs: CRD IG first, DTR IG second, and PAS IG third. A commenter stated there are already states making plans to implement an electronic prior authorization process and suggested that a staggered approach could help to avoid unnecessary variation in implementations. A commenter stated that if CMS does not provide an explanation of terminology (such as “documentation”) and specify IGs and common standards on time for the Prior Authorization API there may need to be a staggered approach for implementing the API. A commenter agreed with CMS's observation that a phased implementation approach would still result in having to request and process prior authorization requests in at least two different manners for a provider working with the same impacted payer, which makes little sense given the difficulties in the current state to even get the HIPAA Referral Certification and Prior Authorization transaction adopted under HIPAA Administrative Simplification. Multiple commenters recommended a 3-year timeframe for phased implementation based on the specific/common services approach. A commenter recommended that instead of using a percentage criterion, CMS should use a 3-year timeframe with year 1 requiring authorization rules, year 2 adding rules to different specialty facilities, and year 3 adding the Prior Authorization API to specific services and care sectors.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As stated at the beginning of this section, we are finalizing a modification to our proposed compliance dates for the Prior Authorization API in 2027. We continue to believe, for the reasons outlined in the CMS Interoperability and Prior Authorization proposed rule and in our responses to comments on this issue, that mandating a phased approach is not necessary. Payers may choose to implement the IGs in a phased approach within their operations, as long as the API is fully functional by the compliance date. Each payer will evaluate the scope of work required to program their prior authorization requirements, build the rules and questionnaires, and develop appropriate testing. For those payers with extensive prior authorization requirements and less structured documentation policies for different benefit packages, the scope will be more significant. However, a phased approach will not change the scope of this work; the IGs provide the road map or instructions for implementation. Use of these guides will help payers determine the scope and level of effort required for the work that must be completed for system changes, as well as operational changes for their organizations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated the phased approach may result in inconsistent implementation and/or fragmentation when it comes to leveraging the Prior Authorization API, as different payers and providers may be at different stages of implementation. Multiple commenters stated that a phased approach could reduce adoption of Prior Authorization API by providers, particularly if certain items or services are listed in the initial rollout and others are not. A commenter noted that the slow and delayed rollout of the Prior Authorization API is unlikely to result in standardized, streamlined, electronic prior authorization experiences for physicians, clinicians, providers, and 
                        <PRTPAGE P="8869"/>
                        health IT vendors. Therefore, multiple commenters supported the full implementation of Prior Authorization API on January 1, 2026.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for affirming that a phased approach could result in inconsistent and fragmented implementation of the Prior Authorization API and reiterate that the decision to provide an additional year for implementation for all impacted payers was made to ensure that the organizations would have sufficient time for training, development, testing, and outreach to providers.
                    </P>
                    <HD SOURCE="HD3">e. Existing Prior Authorization Standards: HIPAA Exceptions for Testing New Standards</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we explained that the X12 278 transaction standard (Version 5010) and NCPDP D.0 are the current standards for electronic prior authorization transactions, adopted by HHS under provisions of HIPAA. Many payers and providers do not use the HIPAA transaction standards, and instead use proprietary payer interfaces and web portals through which providers submit their requests, as well as phone calls or faxes to complete the process for a response. The prior authorization process remains inefficient and burdensome and creates service issues for patients. We provided findings from industry surveys and HHS reports about gaps in the current processes and standards for prior authorization.</P>
                    <P>
                        The Council for Affordable and Quality Health Care (CAQH) Committee on Operating Rules for Information Exchange (CORE) annual report, the CAQH CORE Index, includes data on health plan and provider use of HIPAA standard transactions, and as noted in the proposed rule (at 87 FR 76288), shows that prior authorization using the X12 278 transaction standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.
                        <SU>107</SU>
                        <FTREF/>
                         The 2021 report 
                        <SU>108</SU>
                        <FTREF/>
                         showed an incremental increase in using the X12 278 transaction standard for prior authorization of 26 percent. CAQH CORE published its 2022 report 
                        <SU>109</SU>
                        <FTREF/>
                         in November 2022 with data showing that while medical plans' adoption of the X12 278 transaction standard increased by two percentage points (to 28 percent), it was still low as compared to the other HIPAA transactions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>107</SU>
                             Council for Affordable and Quality Health Care (2019). 2019 CAQH Index: Conducting Electronic Business Transactions: Why Greater Harmonization Across the Industry is Needed. Retrieved from 
                            <E T="03">https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf?token=SP6YxT4u.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             Council for Affordable and Quality Health Care (2021). 2021 CAQH Index: Working Together: Advances in Automation During Unprecedented Times. Retrieved from 
                            <E T="03">https://www.caqh.org/sites/default/files/explorations/index/2021-caqh-index.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             Council for Affordable and Quality Health Care (2022). 2022 CAQH Index: A Decade of Progress. Retrieved from 
                            <E T="03">https://www.caqh.org/sites/default/files/2022-caqh-index-report%20FINAL%20SPREAD%20VERSION.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We received many comments about the adopted HIPAA transaction standard and its intersection with the proposed rule and address applicable comments here.</P>
                    <P>The provisions of this final rule will provide enhancements to the electronic prior authorization process overall. We are finalizing our proposal to require impacted payers to implement a Prior Authorization API that can provide the necessary data to support a payer's use of electronic prior authorization processes.</P>
                    <P>In the proposed rule, we referenced section 1104 of the Affordable Care Act, which amended HIPAA to require that HHS adopt operating rules for HIPAA standard transactions. “Operating rules” are defined at 45 CFR 162.103 as the “necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard, or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.” Operating rules have not been adopted for the X12 278 transaction standard.</P>
                    <P>
                        The NCVHS reviews operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation in accordance with section 1173(g)(4) of the Act. In June 2022, CAQH CORE submitted revised and new operating rules to NCVHS for consideration. In June 2023, NCVHS sent a letter to HHS recommending adoption of revised operating rules for Eligibility &amp; Benefits, Claim Status, and Payment &amp; Remittance Advice transaction standards, as well as a Connectivity operating rule. In that letter, NCVHS recommended that HHS not adopt the proposed CAQH CORE Attachments Prior Authorization Infrastructure operating rule or the CAQH CORE Attachments Health Care Claims Infrastructure operating rule. NCVHS wrote that “[t]he need for these operating rules should be considered only after publication of a final rule adopting a health care attachments transaction standard under HIPAA.” 
                        <SU>110</SU>
                        <FTREF/>
                         Should a future proposal or recommendation for adoption be submitted to HHS, we would evaluate the effect, if any, on the policies included in this final rule. After the publication of this final rule, CMS will continue to evaluate the impact of any NCVHS recommendation and any separate actions by HHS in that regard.
                    </P>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             National Committee on Vital and Health Statistics (2023, June 30). NCVHS Recommendations on Updated and New CAQH CORE Operating Rules to Support Adopted HIPAA Standards. Retrieved from 
                            <E T="03">https://ncvhs.hhs.gov/wp-content/uploads/2023/07/Recommendation-Letter-Updated-and-New-CAQH-CORE-Operating-Rules-June-30-2023_Redacted-508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We also noted in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76289), that in March 2021, HHS approved an application 
                        <SU>111</SU>
                        <FTREF/>
                         from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards to allow testing of an alternative to the adopted HIPAA standard for prior authorization.
                        <SU>112</SU>
                        <FTREF/>
                         The purpose of this exception is to test an automated exchange of a prior authorization request and response using only the FHIR standard and the FHIR IGs recommended in the proposed rule and included in this final rule. Under this exception, participants are testing the prior authorization exchange using a FHIR-to-FHIR exchange using the FHIR standard without using the X12 278 transaction standard. Preliminary findings suggest that this alternative standard can be used successfully to conduct the prior authorization request and response as end-to-end FHIR in a cost-effective, efficient way. Payer and provider groups have presented these preliminary findings in public forums.
                    </P>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception. Retrieved from 
                            <E T="03">https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative simplification website. Centers for Medicare and Medicaid Services (2023, September 6). Go-to-Guidance, Guidance Letters. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative simplification website.
                        <SU>113</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             HHS website with information about § 164.940 (Exceptions Process and Guidance Letters): HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative 
                            <PRTPAGE/>
                            simplification website. Centers for Medicare and Medicaid Services (2023, September 6). Go-to-Guidance, Guidance Letters. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters</E>
                            .
                        </P>
                    </FTNT>
                    <PRTPAGE P="8870"/>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters made statements about the HIPAA exceptions process (45 CFR 162.940) and described various burdens associated with it, including the application process, lack of clarity for the evaluation criteria, and the time for approval. Commenters noted the current exceptions process may serve as a barrier for the industry to take advantage of the opportunity to move interoperability forward and urged CMS to make it less burdensome to accelerate opportunities for entities to beta test new standards and approaches to more efficient data exchange. A commenter recommended that CMS work with HHS or other agencies to improve the HIPAA exceptions process such that it is less onerous and more flexible to facilitate innovation. Another commenter strongly urged CMS to eliminate the requirement for payers to request an exception to any of the HIPAA transaction and code standards. This commenter stated that Da Vinci member exceptions should be discontinued, and CMS should work with other government entities as needed to eliminate the requirement to obtain an exception from the HIPAA standard for organizations seeking to directly exchange data using the FHIR standard without X12 translation. A commenter requested that HHS develop an administrative process or “onramp” for states to request a HIPAA exception for this specific transaction that individual states could utilize at their discretion.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The opportunity to apply for an exception to test an alternative to an adopted standard is established in the HIPAA statute and implemented in regulation at 45 CFR 162.940. Although we appreciate these comments regarding the HIPAA exceptions process, they are out of scope of this rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters stated that the CMS Interoperability and Prior Authorization proposed rule failed to address the limitations of the X12 278 transaction standard. Many others noted that current industry use of the X12 278 transaction standard is very low, noting it is complex and outdated, and thus mandating the conversion of FHIR to the X12 278 transaction standard serves no real value beyond compliance. A commenter discussed how the CAQH CORE Index report consistently reports that full automation for X12 standards for prior authorization lags far behind payment-related use cases. A commenter noted that because of the low use of the X12 278 transaction standard, entities would have to develop an implementation process to complete a FHIR exchange just to convert it to an X12 278 transaction standard. Another commenter noted the industry will continue to have interoperability challenges around the Prior Authorization API capability due to a lack of uniformity if existing issues with the X12 278 transaction standard are not addressed. Multiple commenters requested that CMS consider certain flexibilities in implementation. A commenter recommended that CMS consider a floor versus ceiling approach in which the X12 standard is seen as the floor and a standard FHIR approach using the PAS IG is the ceiling. Multiple commenters recommended that CMS provide a waiver for the X12 278 transaction standard for payers that can implement end-to-end FHIR data exchange. A commenter requested that CMS grant such payers a safe harbor that provides an automatic waiver of the X12 278 transaction standard requirement. A commenter noted these waivers would preferably be automatic or minimally burdensome to obtain. Another commenter recommended CMS allow for exceptions to the requirement of converting Prior Authorization API messages to the X12 278 transaction standard in scenarios where there is no need for the receiving entity to pass along the prior authorization transaction to another system. A commenter sought guidance on whether CMS will consider payers that are not currently covered under the HIPAA administrative simplification exception of having prior authorizations sent through the PAS phase of the Prior Authorization API, translated into and out of the X12 278 transaction standard for an exception. A commenter requested clarification on whether CMS proposed that the Prior Authorization API can be used to transform the provision of a health care attachment into a valid X12 278 transaction standard for meeting HIPAA requirements or is suggesting that the Prior Authorization API provides an alternative basis to the proposed X12 278 transaction standard.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate stakeholder interest in using the FHIR standard to implement the Prior Authorization API. Unless an impacted payer is included in the current Da Vinci pilot to test an exception to the HIPAA transaction, that payer may be required to use the adopted HIPAA standard when implementing the API. Information on the Da Vinci pilot is available on the HL7 Da Vinci website.
                        <SU>114</SU>
                        <FTREF/>
                         The participants in the pilot are testing the prior authorization API over 3 years and will report to HHS at the end of that time on such metrics as response time, ability to exchange supporting clinical information, integration into the provider's workflow, reducing total provider/staff time to obtain prior authorization, flexibility of the standard, ability to provide a timely response, and more. The Prior Authorization API can support the submission of a prior authorization request itself, or provide data that can support the HIPAA-compliant X12 278 transaction standard, if used, for prior authorizations, which is then sent as a separate transmission between the providers and payers, either through a clearinghouse or through the provider's practice management system. HL7 provides detailed workflows and graphical depictions of the API and the HIPAA transaction process.
                        <SU>115</SU>
                        <FTREF/>
                         Finally, this final rule does not address health care attachments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception. Retrieved from 
                            <E T="03">https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             Health Level Seven International (2023, December 1). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from 
                            <E T="03">https://build.fhir.org/ig/HL7/davinci-pas/usecases.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that the lack of requirements for specific data elements with the X12 278 transaction standard for prior authorizations limits the value of that transaction standard and would affect the adoption of the API because providers would lack an efficient way to identify what critical information to include in a prior authorization request. Multiple commenters expressed concern regarding the functionality of the proposal to use the X12 278 transaction standard with the API, and another commenter noted that the X12 275 transaction standard for health care claims attachments does not allow for using FHIR, which creates concerns about the implementation of the Prior Authorization API. Another commenter stated that certain CAQH CORE operating rules to support HIPAA transactions were submitted to NCVHS for review and recommendation to HHS in 2023. These operating rules were specific to certain HIPAA transactions and included required documentation requirements. The commenter noted that the operating rules do not name an API documentation requirement, which is key to locating data in various formats. Finally, another commenter noted that the X12 and FHIR standards 
                        <PRTPAGE P="8871"/>
                        do not currently share compatible coding for all the information that would need to be translated.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the concerns commenters expressed regarding the ability to use the adopted X12 prior authorization transaction with the Prior Authorization API. Code mapping between the X12 standard and the FHIR IGs contains X12 standard proprietary information and will require a license for its use to support the X12 transaction. This mapping is available on the X12 website through the Glass online viewer 
                        <SU>116</SU>
                        <FTREF/>
                         as HL7 does not publish an X12 mapping artifact.
                    </P>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             X12. X12 (2023). Retrieved from 
                            <E T="03">www.X12.org</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We also note that we did not propose in this rulemaking that the X12 275 transaction standard be required for use with the Prior Authorization API. That transaction was proposed for use in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438),
                        <SU>117</SU>
                        <FTREF/>
                         which has not yet been finalized. We reiterate that there are no operating rule requirements in the HIPAA Administrative Simplification rules (45 CFR part 162) applicable to the API required for use in this final rule, or, at this time, to the required HIPAA-compliant X12 278 transaction standard.
                    </P>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             National Archives (2022, December 21). Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard. Retrieved from 
                            <E T="03">https://www.federalregister.gov/documents/2022/12/21/2022-27437/administrative-simplification-adoption-of-standards-for-health-care-attachments-transactions-and</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support to CMS for proposing an electronic Prior Authorization API that uses the FHIR standard and IGs in addition to the adopted X12 278 transaction standard to conduct electronic prior authorization.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenter support for the policy that utilizes both FHIR and X12 transaction standards. The FHIR standard and IGs will be used to implement the Prior Authorization API while supporting compliance with the HIPAA administrative transaction standard.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested support for their organizations that are ready and willing to exchange data using FHIR data and process standards instead of X12 standards. Other commenters recommended that CMS recognize FHIR data and process standards as a permitted option for standard transactions (that is, adopted in place of the X12 standards). These commenters noted that FHIR has increasingly become the de facto standard in health care since it was mandated as a standard in the implementation of the Cures Act. To further accelerate the FHIR standard and exchange of data via FHIR, commenters recommended that CMS work with other government entities to eliminate the need for the HIPAA exception requirement for organizations seeking to exchange data via FHIR directly without X12 transaction standard translation. Some commenters stressed the costs involved in having to comply with both a new set of standards and maintain a system for an outdated standard they were not using and for which they had already developed workarounds. Others suggested that CMS support both X12 and FHIR to meet market needs and innovation. The SDOs supported this approach, noting that the FHIR IG is written in such a way that if the requirement to use the HIPAA standard is removed, the structure is in place for a FHIR-only transaction.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate industry interest in moving towards using the FHIR standard and reiterate that the HIPAA standards are adopted by HHS. HIPAA covered entities may consider submitting comments regarding updates to those standards to the Secretary of HHS for consideration.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters emphasized the importance of exploring the integration of real-time electronic prior authorization transactions into workflows as these could reduce payer costs. A commenter noted that this was also recommended in the 2020 ONC report: “Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs.” A commenter noted these could be used for medical services and medications that do not typically require large amounts of supporting documentation. Another commenter recommended that CMS adopt policies that support integration of electronic prior authorization into physicians' practice workflows such as direct financial support for investments in compliant IT platforms, allowing physicians to access insurer APIs as they work towards full capability, and supporting flexible sources of documentation for prior authorization requests within the established framework. A commenter recommended the electronic prior authorization system be universal across all payers with information displayed in real-time, with no cost to clinicians or health systems. The commenter stated that research showed that switching to real-time electronic prior authorization could save more money and reduce the time a provider takes to complete a transaction by 15 minutes on average. The commenter stated that improving prior authorization processes would benefit every actor in this transaction. Another commenter expressed the importance for CMS to acknowledge that real-time prior authorization should be the goal and that the standards and technology currently exist to implement real-time prior authorization for certain use cases. A commenter recommended that payers implement real-time determination by January 1, 2026, for Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Many commenters discussed the potential the Prior Authorization API and policies in this final rule have for payers to make real-time decisions, particularly when integrated into both the payer and provider workflows; however, we did not propose a real-time decision requirement and are not finalizing such a requirement in this final rule. Though we anticipate that some of the responses or decisions may be made in real-time, we anticipate others will continue to necessitate review and evaluation by clinical staff. We agree that the automation of a complex process such as prior authorization will require continuous improvement. Furthermore, some cases will require manual review because of their complexity. Nonetheless, the overarching improvements in automation will be an improvement in what exists today.
                    </P>
                    <HD SOURCE="HD3">f. Federal Matching Funds for State Medicaid and CHIP Fee-for-Service Programs' Expenditures on Implementation of the Prior Authorization API</HD>
                    <P>In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the Prior Authorization API (this was also addressed in the proposed rule at 87 FR 76291 and 76292).</P>
                    <HD SOURCE="HD3">g. Medicaid Expansion CHIP</HD>
                    <P>In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76292).</P>
                    <HD SOURCE="HD3">3. Requirement for Payers To Provide Reason for Denial of Prior Authorizations and Notifications</HD>
                    <P>
                        Throughout the Interoperability and Prior Authorization proposed rule at 87 FR 76292, we described opportunities for improvement with the prior authorization process, specifically 
                        <PRTPAGE P="8872"/>
                        where better communication between payers and providers could mitigate confusion about the status of a prior authorization, particularly if it was not approved. This section addresses issues about the proposed and final policy for communication about prior authorization denials and existing requirements for notifications from impacted payers.
                    </P>
                    <HD SOURCE="HD3">a. Background on Providing a Reason for Denial of Prior Authorization</HD>
                    <P>Payers deny prior authorizations for different reasons, including because the payer does not consider the items or services to be medically necessary, the patient exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. When a payer provides a specific reason for a denial, a provider can take appropriate actions such as re-submitting the request with updated information, identifying alternatives for the patient, appealing the decision, or communicating the decision to the patient to enable the patient to consider other options or to appeal as well. Today, impacted payers send denials either electronically or through the mail, and the information provided varies substantially between payers. For denials sent using the X12 278 transaction standard, payers must use the codes from the external code set maintained by X12. For responses sent through portals, fax, or other means, payers may use proprietary codes or text to communicate denial reasons. The process is inefficient and unsatisfactory; and in general, providers do not have consistent direction on the next steps for a denied authorization. Our proposal for impacted payers to send a specific denial reason was one approach to address current inefficiencies.</P>
                    <P>We proposed, and are finalizing in this final rule, that, beginning in 2026, impacted payers must provide a specific reason for denied prior authorization decisions, regardless of the method used to send the prior authorization request. As with all policies in this final rule, this provision does not apply to prior authorization decisions for drugs. This final policy is an effort to improve the communication about denials from an impacted payer in response to a request for a prior authorization through existing mechanisms, such as electronic portals, telephone calls, email, standard transactions, or other means.</P>
                    <HD SOURCE="HD3">b. Denial Reason and Denial/Decision Codes</HD>
                    <P>Some payers subject to this requirement to provide a specific reason for denied prior authorization decisions will also remain subject to existing requirements to provide notice to patients, providers, or both, with the specific reasons for the denial. In addition, for certain payers impacted by this final rule, existing communication requirements related to coverage decisions, notices of coverage decisions, and appeal processes, remain in effect for coverage decisions that are made as part of a prior authorization denial or approval. These requirements are not changed under this final rule. For example, before an MA plan may issue a prior authorization denial (or any other organization determination that is a denial) based on medical necessity, the decision must be reviewed by a physician or other appropriate health care professional with expertise in the field of medicine or health care that is appropriate for the services being requested, including knowledge of Medicare coverage criteria, per 42 CFR 422.566(d); this will apply to any denial of a prior authorization request, regardless of whether the Prior Authorization API has been used to request, check the status of, or communicate the decision on the prior authorization. Nothing in this final rule limits the scope of the MA regulation at 42 CFR 422.566(d) and it continues to apply to any prior authorization request and decision that is also subject to the policies being finalized in this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that CMS define and provide examples for terms such as “approval,” “denial,” and “specific reason” concerning prior authorization denials in the final rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are not adding regulatory definitions for these terms in this rule, as these terms are clear, frequently used in many contexts, and commonly used. For this final rule, these terms mean the following:
                    </P>
                    <P>• Approvals are when the payer authorizes coverage of items or services for which prior authorization has been requested.</P>
                    <P>• Denials are the refusal by a payer to approve the prior authorization for a health care item or service. Denials, or rejection of a prior authorization, may result because the service was not considered medically necessary under the payer's medical guidelines or the provider did not provide complete or accurate documentation to support the request.</P>
                    <P>• A specific reason for denial could include reference to the specific plan provisions on which the denial is based; information about or a citation to coverage criteria; how documentation did not support a plan of care for the therapy or service; a narrative explanation of why the request was denied, and specifically, why the service is not deemed necessary or that claim history demonstrated that the patient had already received a similar service or item.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed their support for CMS's proposal to require impacted payers to provide specific reasons for prior authorization denials, regardless of the mechanism used to submit the prior authorization request. Multiple commenters also specifically expressed support for requiring impacted payers to provide the reasons for denial as part of the information included in the Prior Authorization and Patient Access APIs. Similarly, commenters expressed support for CMS's proposal to require impacted payers, particularly MA organizations, to give providers specific reasons for their prior authorization denials. Many commenters supported the proposal to require payers to include in the Prior Authorization API specific information about prior authorization requests, including the determination of approval (and for how long), determination of denial (with a specific reason), and a request for more information from a provider.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the general support for the proposal to improve this aspect of the prior authorization process, specifically communication about prior authorization decisions and information about denials.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters noted that requiring a reason for denials and public reporting of prior authorization metrics could help providers, patients, policymakers, and other interested parties understand the prior authorization process better. These commenters asserted that this increased transparency could improve providers' submissions of prior authorization requests, ensure prior authorizations are based on the best medical evidence and guidelines, and allow patients to be better informed regarding their health care purchasing decisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the many other comments we received in support of the proposals to require a reason for denials and public reporting and discuss other comments specific to those provisions later in this section. Specifically, we concur that the transparency of information will support communication between payers, providers, and patients.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS be more specific about which prior authorization decision information payers should 
                        <PRTPAGE P="8873"/>
                        include as well as how they should provide this information. Specifically, multiple commenters recommended that CMS further specify the level of detail that impacted payers must provide about their reasons for denial. Other commenters recommended that the information payers provide regarding reasons for prior authorization denials include the policy on which the decision was based and the requirements for coverage assessed, including the standards used to determine medical necessity. The commenters recommended that CMS require that the reason for denial provided by payers include the clinical rationale and patient-specific evidence supporting the denial decision (that is, which specific criteria the patient did not meet). A commenter recommended that CMS require payers to provide the following with each prior authorization decision: whether the prior authorization adjudication was automatically adjudicated; whether statistical methods such as AI, machine learning, or other algorithms were used; and whether a human decision-maker was involved and the name and credentials of the employee. This commenter noted algorithms should be publicly accessible so that they can be examined for implicit bias. Another commenter recommended that CMS require impacted payers to provide a clinical rationale for prior authorization denials according to the national medical specialty society guidelines for peer-reviewed clinical literature. Multiple commenters recommended that CMS specify that impacted health plans must provide all the prior authorization decision and denial information in a form that is understandable and outlines specific steps for the provider, including any additional information the provider needs to provide to further support the request, a list of covered alternative treatments, and details regarding their right to appeal and the process for appeals.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In this final rule, we are requiring impacted payers to provide a specific reason to the provider when denying a prior authorization. The volume of comments in this area, as in other areas of these proposals, was indicative of the challenges providers face in obtaining specific information about prior authorization decisions and denials, and that payers face in providing adequate detail for the decisions they give back to a provider about a prior authorization denial, such that the provider can take appropriate action. The CMS Interoperability and Prior Authorization proposed rule and this final rule do not directly address how prior authorization decisions are made, such as using AI, statistical methods, requirements for clinical decisions, or other algorithms, which are out of scope of this specific rulemaking. However, prior authorization decisions involving AI or other algorithmic systems must still comply with applicable requirements, including requirements around clinical decision-making and the finalized policy requiring communication of the specific reason for denial. This rule intends to ensure that payers provide better communication about denials than has been available to date.
                    </P>
                    <P>
                        There are existing programmatic rules for some of the impacted payers that also address the content of a denial decision. MA organizations 
                        <SU>118</SU>
                        <FTREF/>
                         are required to provide the specific reasons for the denial to their enrollees when an item or service is denied, along with certain other information (such as the ability to appeal the decision and how). CMS provides a standard form for MA organization use, which captures a specific and detailed explanation of why the medical services were denied, including a description of the applicable coverage rule or applicable plan policy (for example, Evidence of Coverage provision) upon which the action was based, and a specific explanation about what information is needed to approve coverage if applicable. For Medicaid managed care prior authorization decisions, 42 CFR 438.210(b) requires the MCO, PIHP, or PAHP contract with the state to include provisions requiring the Medicaid managed care plan to consult with the requesting provider when appropriate and that any decision to deny a service authorization request or to authorize a service in an amount, duration, or scope that is less than requested, be made by an individual who has appropriate expertise in addressing the enrollee's medical, behavioral health, or long-term services and supports needs. The regulation at 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider of the Medicaid managed care plan's denial of a service authorization request, or decision to authorize a service in an amount, duration, or scope that is less than requested. For Medicaid FFS, 42 CFR 435.917(a) requires state Medicaid agencies to provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary's prior authorization request, as any such decision would cause a “denial or change in benefits and services.” 
                        <SU>119</SU>
                        <FTREF/>
                         When a state denies the prior authorization request in whole or in part, the beneficiary notice must include, in addition to the content described at 42 CFR 435.917, the notice content described at 42 CFR part 431, subpart E, including the requirement at 42 CFR 431.210 that notices contain a clear statement of the specific reasons supporting the intended action. Notices must be written in plain language and be accessible to individuals who have limited English proficiency and individuals with disabilities consistent with 42 CFR 435.905(b). These existing provisions, which include a requirement for enrollees to be provided written notice about an adverse decision, could be useful examples for the level of specificity that could be given to a provider, including the applicable medical necessity criteria. Likewise, for CHIP managed care entities' prior authorization decisions, 42 CFR 457.1230(d) cross references to 42 CFR 438.210 to apply Medicaid managed care plans' prior authorization decision requirements to CHIP managed care entities. Additionally, for QHP issuers on the FFEs, 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-1(g) and (j) require group health plans and issuers of group and individual health insurance coverage to provide notice to individuals, in a culturally and linguistically appropriate manner, of adverse benefit determination or final internal adverse benefit determination and specifies information that this notice must include, such as a description of the plan's or issuer's standard, if any, that was used in denying the claim.
                    </P>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(e).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             
                            <E T="03">See</E>
                             42 CFR 435.917(a).
                        </P>
                    </FTNT>
                    <P>When denial information is sent to a provider by any communication method, including existing notices, the content of a denial should be sufficiently specific to enable a provider to understand why a prior authorization has been denied and what actions must be taken to re-submit or appeal. This requirement would improve the current processes and reduce manual effort and costs. When implemented, the Prior Authorization API could mitigate some denials by providing information about the documentation and information or data necessary to support a prior authorization request for the service or item.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS work with X12 and other appropriate industry organizations to update the X12 278 Service Decision Reason Code Set with additional codes for scenarios not yet covered by the existing code set or for 
                        <PRTPAGE P="8874"/>
                        use of the X12 Service Decision Reason Codes as the code set for communicating reasons for the denial. The X12 Service Decision Reason Code List is a code set maintained by X12 used by HIPAA covered entities with the HIPAA standard transaction for electronic prior authorization decisions. A commenter supported using denial codes under the condition that CMS continue to work with SDOs, NCVHS, and other relevant organizations to expand the denial reasons and add support for more specific options. Another commenter requested clarification on whether the specific reason for the denial requirement must be met by using the X12 code list of denial reasons. The commenter added that this code list allows varying interpretations which would result in ambiguity. Other commenters recommended that CMS establish a clearly defined standardized set of specific reasons for the denial and require payers to use them for communicating prior authorization decisions for all items and services. A commenter recommended that CMS align the FHIR Certification Action Codes and the X12 Service Decision Reason Codes. Another commenter stated that the HCR 03 Decision Reason Code is an optional field in the X12 278 transaction standard and recommended that CMS refer to “denial reasons” as “decision reason codes.”
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that the X12 Service Decision Reason Code List is a code set maintained by X12 for electronic prior authorization decisions. Updates to this code set must be requested through the X12 code maintenance workgroup. We strongly encourage both impacted payers and providers to evaluate the X12 Decision Reason Code List and make recommendations to X12 for necessary updated or new codes as appropriate. We encourage interested organizations and SDOs to continue their collaboration efforts on crosswalks needed for the IGs supporting the Prior Authorization API and maintenance of code sets that could be used with the API. We decline to change the terminology in this final rule from “reason for the denial” to “decision reasons” or “decision reason codes.” The obligation under this final rule for impacted payers to provide a specific reason for the denial of a prior authorization request goes beyond using a single code set and means that payers must provide sufficient detail in the denial response to enable the provider to know what action to take as the follow-up to the denial to obtain coverage—that is whether to appeal, submit additional documentation, or identify alternative treatment options. Impacted payers may send additional information through the API which could provide additional clarity. Finally, though the Medicare FFS program has a list of decision reason codes in use for its program, and these could be considered for inclusion in the X12 code set, we did not propose these for use by all payers as part of this policy. However, the industry could submit similar text to X12 as additions to that external code set. We affirm that all denial reasons must be specific.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters shared concerns about and made recommendations related to MA organizations' utilization management policies as these pertain to the denial of prior authorizations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         This rulemaking does not address requirements or limitations for all utilization management guidelines or policies used by MA organizations. This rulemaking adopts certain procedural and timing requirements for prior authorizations and several API requirements for MA organizations and other impacted payers, including implementation of a Prior Authorization API, new reporting to CMS, and new requirements to provide to the applicable provider a specific reason for the denial of a request for prior authorization. However, in separate rulemaking for MA organizations, we addressed standards and requirements for how MA organizations develop and use clinical criteria and prior authorization policies to help ensure MA beneficiaries receive the same medically necessary care they would receive under Traditional Medicare in the CY 2024 MA and Part D final rule (88 FR 22120).
                        <SU>120</SU>
                        <FTREF/>
                         We recommend interested readers review the CY 2024 MA and Part D final rule for more information on these other requirements for MA organizations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             
                            <E T="03">See also</E>
                             42 CFR 422.101(b)(6), 422.112(b)(8), 422.137, and 422.138.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters described challenges with denials, including the burdens they faced when attempting to appeal those denials on behalf of their patients and delays created in access to care when they did not have information about the reason for the denial, and therefore little information to include in the response back to the payer. Multiple commenters wrote that requiring impacted payers to provide reasons for prior authorization denials would have positive impacts on the health care system. Multiple commenters stated that this requirement would facilitate better transparency and communication between providers and payers. Commenters noted that this requirement would: (1) allow providers to better communicate the reason for denial and reasons for potential treatment plan changes to their patients; (2) provide patients with more insight into how decisions are made relating to access to care; (3) decrease the number of arbitrary prior authorization denials and minimize the number of denials that are overturned on appeal; and 4) reduce unnecessary delays in patient care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the many letters from commenters indicating support for the provisions of this rule and including in those letters descriptions of the process challenges that they believe could be mitigated by the policies being finalized. We concur with the information in many of the letters that the requirement to provide the specific reason for the denial in a response to the provider has the potential to improve communication between payers and providers for the prior authorization process.
                    </P>
                    <HD SOURCE="HD3">c. Existing Notice Requirements To Communicate Prior Authorization Denial Information—By Program</HD>
                    <P>Some of the impacted payers are required by existing Federal and state laws and regulations to notify providers or patients when the payer makes an adverse decision on a prior authorization request. Our proposals to impose requirements on payers to communicate certain information to providers about prior authorization denials were intended to reinforce and supplement existing Federal and state requirements and do not alter or replace existing requirements to provide notice to patients, providers, or both. Further, the requirements include implementation of a Prior Authorization API that can provide responses about whether an authorization request has been approved (and for how long) or denied, a specific reason for the denial, or request more information from the provider to support the prior authorization. Communicating denial reasons with specific information, in addition to the existing program notification requirements, will increase transparency, reduce burden, and improve efficiencies for both payers and providers. The API requirements have compliance dates in 2027.</P>
                    <HD SOURCE="HD3">i. Denial Notice Requirements</HD>
                    <P>
                        This section of the final rule addresses denial notice requirements which will remain in place for MA organizations, CHIP FFS, Medicaid 
                        <PRTPAGE P="8875"/>
                        managed care plans, and CHIP managed care entities.
                    </P>
                    <P>
                        Under the MA program, the actions that constitute an “organization determination” include a prior authorization decision (as well as a decision in response to a voluntary pre-service request for a decision on coverage), as it is defined as including an MA organization's refusal to provide or pay for services, in whole or in part, including the type or level of services that the enrollee believes should be furnished or arranged by the MA organization as well as other types of decisions about coverage and payment.
                        <SU>121</SU>
                        <FTREF/>
                         Existing MA program regulations impose requirements as to the form and content of the written notice to enrollees in the event of a partial or full denial. For example, existing regulations regarding written notices for enrollees for standard organization determinations require that notice for any denial by the plan of coverage of an otherwise covered service or item must—
                    </P>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.566(b).
                        </P>
                    </FTNT>
                    <P>• Use approved notice language in a readable and understandable form;</P>
                    <P>• State the specific reasons for the denial;</P>
                    <P>• Inform the enrollee of their right to a reconsideration;</P>
                    <P>• Describe both the standard and expedited reconsideration processes, including the enrollee's right to, and conditions for, obtaining an expedited reconsideration and the rest of the appeal process; and</P>
                    <P>
                        • Comply with any other notice requirements specified by CMS.
                        <SU>122</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(e).
                        </P>
                    </FTNT>
                    <P>
                        Under existing requirements,
                        <SU>123</SU>
                        <FTREF/>
                         if the MA organization expedites an organization determination, the MA organization must notify the enrollee (or the enrollee's representative) and the physician involved, as appropriate, of its decision, whether adverse or favorable, as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request. Either an enrollee or a physician, regardless of whether the physician is affiliated with the MA organization, may request that an MA organization expedite an organization determination.
                        <SU>124</SU>
                        <FTREF/>
                         The notice of expedited determination must state the specific reasons for the determination in understandable language and if the determination is not completely favorable to the enrollee, the notice must also—
                    </P>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.572.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.570.
                        </P>
                    </FTNT>
                    <P>• Inform the enrollee of their right to a reconsideration;</P>
                    <P>• Describe both the standard and expedited reconsideration processes, including the enrollee's right to request, and conditions for obtaining an expedited reconsideration, and the rest of the appeal process; and</P>
                    <P>
                        • Comply with any other requirements specified by CMS as to the content of the notice.
                        <SU>125</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.572.
                        </P>
                    </FTNT>
                    <P>
                        Because applicable integrated plans (D-SNPs that have exclusively aligned enrollment with an affiliated Medicaid MCO) are a type of MA plan, the regulations regarding prior authorization processes that we are finalizing apply to them. The final rule revises the specific timeframes for prior authorization decisions by applicable integrated plans. Applicable integrated plans cover both Medicaid long term services and supports and MA benefits in ten states. Existing requirements already govern denial notices issued by applicable integrated plans to their enrollees and are similar to the Medicaid managed care and MA rules described in the prior paragraphs.
                        <SU>126</SU>
                        <FTREF/>
                         Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain—
                    </P>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.631.
                        </P>
                    </FTNT>
                    <P>• The applicable integrated plan's determination;</P>
                    <P>• The date the determination was made;</P>
                    <P>• The date the determination will take effect;</P>
                    <P>• The reasons for the determination;</P>
                    <P>• The enrollee's right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee's behalf;</P>
                    <P>• Procedures for exercising an enrollee's rights to an integrated reconsideration;</P>
                    <P>• The circumstances under which expedited resolution is available and how to request it; and</P>
                    <P>• If applicable, the enrollee's rights to have benefits continue pending the resolution of the integrated appeal process.</P>
                    <P>As with the notices required from MA plans, our finalized policies do not change the content requirements for these written denial notices to enrollees but will supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request.</P>
                    <P>For Medicaid managed care plans and CHIP managed care entities, existing regulations at 42 CFR 438.210(c) require notice to the provider without specifying the format or method, while 42 CFR 438.210(c) and 438.404(a) require written notice to the enrollee of an adverse benefit determination. In addition, 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider as well of the Medicaid managed care plan's denial of a service authorization request or decision to authorize a service in an amount, duration, or scope that is less than requested. CHIP managed care entities are required to comply with similar standards at 42 CFR 457.1230(d) (referencing 42 CFR 438.210) and 457.1260(c) (referencing 42 CFR 438.404). Nothing in this final rule will limit the existing enrollee notification requirements at 42 CFR part 438 for Medicaid managed care plans and at 42 CFR part 457 for CHIP managed care entities as these requirements will remain in full effect. This final rule fills a potential gap concerning the information communicated to providers regarding a denial of a prior authorization request. We proposed and are finalizing that the response—whether the authorization request has been approved (and for how long), denied (with the reason for the denial), or a request for more information to support the prior authorization—if transmitted to providers via the Prior Authorization API workflow process or other means, will be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c) and 457.1230(d). We are finalizing a slight modification to the regulatory language to use “the date or circumstance under which the authorization ends” instead of “how long” as the scope of information that must be provided by the payer. The payer will not be required to send the response to the provider via both the Prior Authorization API (which is required to furnish certain information, including denial reason) and a separate, additional manner (for example, separate written notice or phone call) with duplicate information. However, given that providers are not required to use the Prior Authorization API, the payer must ensure that the response to the provider with the reason for the denial must be furnished to the provider through some means.</P>
                    <P>
                        We also remind all Medicaid managed care plans and CHIP managed care entities subject to this final rule that their existing obligations to provide these required notices to patients are not changed by the final policies in this rule. These payers will still have to 
                        <PRTPAGE P="8876"/>
                        provide a separate written notice to the enrollee.
                    </P>
                    <P>
                        QHP issuers on the FFEs that offer individual health insurance must provide the specific reason for an adverse benefit determination, which includes denial of prior authorization.
                        <SU>127</SU>
                        <FTREF/>
                         Furthermore, plans and issuers must ensure that notice is made to individuals in a culturally and linguistically appropriate manner that complies with existing requirements.
                        <SU>128</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             
                            <E T="03">See</E>
                             45 CFR 147.136(b)(3)(ii)(E).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             
                            <E T="03">See</E>
                             CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-1(g) and (j).
                        </P>
                    </FTNT>
                    <P>
                        Finally, impacted payers may be required to provide this information in languages other than English, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities.
                        <SU>129</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             
                            <E T="03">See</E>
                             45 CFR 92.3 and 92.101.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Notice and Payer Communications</HD>
                    <P>We received comments on the current processes for notice and payer communications and summarize those and our responses here. Generally, such processes exist for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed frustration with the variation of prior authorization requirements across MA plans, inconsistencies in access to care and coverage, and painful interactions during lengthy peer-to-peer review of medical necessity assessments with MA organizations. A commenter expressed support for the proposal in the CY 2024 MA and Part D proposed rule (87 FR 79452) to prohibit MA plans from diverting a patient to a different level of care than recommended by the patient's physician when the patient otherwise meets all the clinical criteria appropriate for the setting requested by the physician. Commenters noted these factors have contributed to a more complicated prior authorization process, extended wait times, duplicate or inaccurate prior authorization denials and post-claim denials, and a shifting focus from patient care. Multiple commenters recommended CMS implement increased oversight policies to address MA's challenging prior authorization landscape. Multiple commenters recommended that CMS continue to oversee MA plans' use of prior authorization and advance policies that ensure that MA enrollees have the same access to covered services as those enrolled in Traditional Medicare and that MA organizations cannot use more stringent criteria than Traditional Medicare.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As finalized in the CY 2024 MA and Part D final rule, 42 CFR 422.138 provides that coordinated care plan prior authorization policies may only be used to confirm the presence of diagnoses or other medical criteria and/or ensure that an item or service is medically necessary. Second, the CY 2024 MA and Part D final rule requires coordinated care plans to provide a minimum 90-day transition period when an enrollee currently undergoing treatment switches to a new MA plan, during which the new MA plan may not require prior authorization for the active course of treatment (42 CFR 422.112(b)(8)(ii)(B)). Third, to ensure prior authorization is being used appropriately, we are requiring all MA plans that use utilization management policies (like prior authorization) to establish a Utilization Management Committee to review policies annually and ensure consistency with Traditional Medicare's NCDs, LCDs, and guidelines; compliance with limits on how prior authorization can be used; compliance with other MA regulations on determining medical necessity (42 CFR 422.101(c)); and consultation with network providers (42 CFR 422.202(b) and 422.137). Finally, to address concerns that the CY 2024 MA and Part D proposed rule did not sufficiently define the expected duration of “course of treatment,” a newly adopted regulation at 42 CFR 422.112(b)(8) requires that a coordinated care MA plan's approval of a prior authorization request for a course of treatment must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient's medical history, and the treating provider's recommendation. The CY 2024 MA and Part D final rule and this final rule taken together provide significant guardrails for prior authorization in the MA program and support a more streamlined process, which will ultimately lead to reduced burden in health care.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter was concerned that without specific guidance for MA plans regarding certain benefits, the proposed rule will negatively impact the already existing barriers to electronic exchange of information between MA organizations and religious nonmedical health care institution (RNHCI) providers. This commenter supported the concept of the Prior Authorization API because it makes possible the electronic exchange of certain prior authorization information between payers and providers, which RNHCIs have long desired. However, the organization was concerned about the requirement at 42 CFR 422.122(b) because of concerns about its applicability to nonmedical benefits. This commenter proposed amendments to the regulatory text regarding the obligation to accept and exchange information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The requirements proposed at 42 CFR 422.122(b) apply to all covered Medicare services, including covered items and services furnished by a RNHCI, and all MA supplemental benefits covered by an MA plan, excluding all drugs, as defined at 42 CFR 422.119(b)(1)(v). See section I.D. for more information about the exclusion of drugs from the scope of the prior authorization policies in this rule.
                    </P>
                    <P>We are finalizing that the prior authorization requirements adopted in this final rule supplement and do not replace requirements in other applicable laws, including existing requirements for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs regarding decisions made on requests for prior authorization of covered benefits. For additional explanation on the continued applicability of existing standards in this final rule, we are adding paragraph (b)(5) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable MA requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. Under existing standards for Medicaid managed care plans, all prior authorization decisions by Medicaid managed care plans must comply with 42 CFR 438.210 as well as notice requirements at 42 CFR 438.404.</P>
                    <HD SOURCE="HD3">4. Requirements for Prior Authorization Decision Timeframes and Communications</HD>
                    <HD SOURCE="HD3">a. Impact of Delays in Prior Authorization Decisions: Background of Decision Timeframes</HD>
                    <P>
                        As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76294), CMS learned through listening sessions and other public meetings that excessive wait time for prior authorization decisions could cause delays to patient care and create medical risks in some cases. Providers face delays for the approval of the initial request, or, secondarily, for the resolution of a request “in process,” often meaning the payer is reviewing requested documentation. In 2019, CMS 
                        <PRTPAGE P="8877"/>
                        conducted outreach to external entities (87 FR 76294) and received many comments about timeframes for processing prior authorizations, where commenters explained that the process of securing approvals for prior authorization directly affects patient care by delaying access to services, including transfers between hospitals and post-acute care facilities, treatment, medication, and supplies. Commenters believed that these delays occur partly because payers have different policies and review processes, do not use available technologies consistently, and continue to rely on manual systems such as phone, fax, and mail, which are more labor-intensive.
                    </P>
                    <HD SOURCE="HD3">b. Standard and Expedited Prior Authorization Requests and Decision Timeframes</HD>
                    <P>
                        In the CMS Interoperability and Prior Authorization proposed rule we used the terms standard and expedited prior authorizations to refer to two types of prior authorizations for which we are now finalizing our policies—in this final rule, we affirm that the term “standard” prior authorization refers to non-expedited, non-urgent requests and the term “expedited” prior authorization indicates an urgent request. These terms continue to be used in CMS regulations.
                        <SU>130</SU>
                        <FTREF/>
                         We received a few comments on these terms and respond to those here.
                    </P>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans and 42 CFR 438.210(d) and 438.404 for Medicaid managed care plans.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that there was a lack of clarity and guidance on the definition of a standard versus an expedited prior authorization. A commenter recommended that CMS create additional specificity around what “expedited” means, especially for mental health and substance use disorder conditions. Another commenter stated that what one provider may deem an expedited request may not be considered one by the payer. A commenter noted that the lack of a standard definition leads to discrepancies on what a payer considers “urgent” and sometimes leaves some discretion up to the provider. This lack of standardization can adversely affect a patient. If a payer has a stricter definition of what constitutes an expedited prior authorization, this could lead to the patient waiting up to 7 days for a decision and delay access to care further if prior authorization is denied. Commenters stated that CMS should release guidance on definitions of these terms to facilitate more alignment for payers and strengthen patient access by minimizing variation between network standards on what is considered “urgent” versus “normal.” Another commenter requested that CMS provide clarification on timeframes in emergencies and if emergency care would override prior authorization rules.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We decline to create a new definition for standard and expedited, as the definitions for standard and expedited requests provide a foundation upon which both payers and providers can rely for making professional judgments. These terms are used in the provisions at 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans. Similar terms are used at 42 CFR 438.210(d) for Medicaid managed care plans, at 42 CFR 457.1230(d) for CHIP managed care entities (87 FR 76294), and we are adding requirements at 42 CR 440.230 for Medicaid FFS and at 42 CFR 457.495 for CHIP FFS to meet these timelines—specifically, as expeditiously as a beneficiary's health condition requires, that may not exceed either 7 calendar days or 72 hours after receiving the request for standard or expedited requests respectively.
                    </P>
                    <P>
                        A standard for when expedited determinations are required currently exists for MA organizations at 42 CFR 422.566(a), which requires MA organizations to have an expedited procedure for situations in which applying the standard procedure could seriously jeopardize the enrollee's life, health, or ability to regain maximum function.
                        <SU>131</SU>
                        <FTREF/>
                         This long-standing medical exigency standard is familiar to MA plans and providers and affords sufficient guidance on when an expedited decision is necessary. There is adequate guidance on these standards for the MA appeals and organization determination deadlines already. For Medicaid managed care and (by cross reference) CHIP managed care, 42 CFR 438.210(d)(2)(i) specifies an expedited authorization is required when “following the standard timeframe could seriously jeopardize the enrollee's life or health or ability to attain, maintain, or regain maximum function.” Standard prior authorization requests are used when the enrollee's life or health or ability to attain, maintain, or regain maximum function are not seriously jeopardized by the managed care plan using the longer, standard authorization timeframes. These policies are intended to ensure that impacted payers, including Medicaid FFS, Medicaid managed care plans, and CHIP managed care entities will evaluate expedited prior authorization review procedures that will minimize patient risk. We confirm that MA plans, Medicaid managed care plans, and CHIP managed care entities are prohibited from applying prior authorization requirements to evaluation and stabilization services for emergency medical conditions.
                        <SU>132</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.570 and 422.572.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             
                            <E T="03">See</E>
                             sections 1852(d), 1932(b)(2), and 2103(f)(3) of the Act and 42 CFR 422.113, 438.114, and 457.1228.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter asserted that eliminating the need for a provider to reach out to a payer and notify them of a request that requires an expedited response would reduce a provider's administrative burden and further the efficiency of the prior authorization process. The commenter recommended CMS request that payers be required to have systems that enable providers to electronically differentiate between standard and expedited prior authorization requests.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While this final rule addresses several important prior authorization processes, it does not specifically dictate all payer operational procedures. Existing regulations in the applicable programs covered by this final rule may address the circumstances under which a payer must make a coverage decision, such as a prior authorization request on an expedited basis. For example, under the MA rules at 42 CFR 422.570, an enrollee or a physician (regardless of whether the physician is affiliated with the MA organization) may request that an MA organization expedite an organization determination involving a request for an item or service. The MA organization must promptly decide whether to expedite an organization determination. Under the rules at 42 CFR 422.570(c)(2), if a request is made by an enrollee, the MA organization must provide an expedited determination if it determines that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee's ability to regain maximum function. If a request for an expedited decision is made or supported by a physician, the MA organization must provide an expedited determination if the physician indicates that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee's ability to regain maximum function. The existing medical exigency standard related to expedited requests will continue to 
                        <PRTPAGE P="8878"/>
                        apply to organization determinations that involve prior authorization.
                    </P>
                    <P>The recommended PAS IG may not currently have the instructions to provide the capability to differentiate between standard and expedited prior authorization requests. However, this data element could be a helpful addition for the next version, and interested parties are encouraged to discuss this at an HL7 workgroup meeting. There may be other means through the payer's Prior Authorization API to determine how an indicator for the type of prior authorization request might be incorporated. The current version of FHIR includes a required data element to indicate the urgency of a request. In FHIR technical terminology, this required data element is named “claim.priority.” However, there is no equivalent value in the HIPAA X12 278 transaction standard or the X12 external code lists because that data element is not required in that standard. The PAS IG does not provide any mapping to X12. For those entities conducting the end-to-end FHIR exchange, the information about expedited and standard prior authorization requests is available to them through the FHIR claim.priority data element. As noted, the X12 278 transaction standard does not include this information because the current version of the X12 278 transaction standard for prior authorizations does not support this concept. An alternative to using the claim.priority data element when using the X12 278 transaction standard for expedited requests would be to include a service date, to indicate urgency.</P>
                    <HD SOURCE="HD3">c. Decision Timeframes for Standard and Expedited Prior Authorization Requests</HD>
                    <P>
                        To improve patient care outcomes and ensure that patients have more timely access to services, we are finalizing our proposals to create, improve, or shorten prior authorization timeframes for certain payers to respond to prior authorization requests for covered items and services, excluding drugs. Specifically, we are finalizing that these timeframes would be 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law,
                        <SU>133</SU>
                        <FTREF/>
                         and 7 calendar days for standard requests with the possibility of an extension to up to 14 days in certain circumstances. We acknowledged that some of the payers affected by this final rule had different requirements for prior authorization decision notice and appeal timeframes, and we are aligning the prior authorization decision timeframes across those payers except for QHPs on the FFEs, as further discussed. For some payers, the existing regulation already uses the timeframe we are adopting in this final rule for standard or expedited requests for prior authorization; those regulations will continue to apply while amendments to adopt the new timeframes for other payers will apply to their prior authorization decisions, beginning in 2026.
                    </P>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             The final policies adopted here for state Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care entities at 42 CFR 438.210 and 457.495(d)(2), respectively, include that a state may set a shorter timeframe for these decisions. However, such state authority does not apply to MA plans operating in these states.
                        </P>
                    </FTNT>
                    <P>
                        In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76295), we provided a chart identifying which regulations we proposed to modify the decision timeframes for standard prior authorization decisions made by MA organizations and applicable integrated plans, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.
                        <SU>134</SU>
                        <FTREF/>
                         Table E1 at the end of this section provides the final Federal requirements for prior authorization decision timeframes that will apply to each payer beginning in 2026.
                    </P>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), 438.210(d)(2), and 457.1230(d).
                        </P>
                    </FTNT>
                    <P>We did not propose to change any existing timeframes that might apply to expedited authorization decisions made by any of the impacted payers, especially given that many of these payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency and correctly describe the new timeframes being finalized for these payers to provide notice of standard determinations, we proposed and are finalizing certain conforming amendments to the CFR sections listed in Table E2.</P>
                    <P>QHPs are not included in the policy on timeframes for the reasons described at the end of this section. Note that these timeframes do not apply to any drugs, as discussed in section I.D. of this final rule.</P>
                    <P>We proposed that beginning January 1, 2026, MA organizations and applicable integrated plans must provide notice of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests. For MA organizations, on or after January 1, 2026, prior authorization requests for items and services covered by the finalized requirements at 42 CFR 422.122 will be affected by this final rule; for all other items and services, existing timeframes under the MA regulations for other pre-service requests for an organization determination would remain applicable. These deadlines are reflected in amendments to 42 CFR 422.568(b)(1) (for MA plans) and 422.631(d)(2)(i) (for applicable integrated plans).</P>
                    <P>We proposed and are finalizing conforming amendments to certain regulations that reference or describe the timeframes that are being amended in this final rule. Specifically, we proposed and are finalizing an amendment to the MA program regulation at 42 CFR 422.570; the revision replaces references to the specific length of the timeframe for standard decisions with a general reference to 42 CFR 422.568 which we are also amending to include the new timeframe(s) for prior authorization decisions for items and services.</P>
                    <P>
                        In addition, this final rule does not change existing Federal timeframes for expedited and standard determinations on requests for Part B drugs for MA organizations and applicable integrated plans; current regulations require notice to the enrollee as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request for a standard determination and as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request.
                        <SU>135</SU>
                        <FTREF/>
                         Due to the finalized revisions to 42 CFR 422.568(b), we are redesignating existing 42 CFR 422.568(b)(2) related to requests for Part B drugs for MA organizations to 42 CFR 422.568(b)(3).
                    </P>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(b)(3), 422.572(a)(2), and 422.631(a).
                        </P>
                    </FTNT>
                    <P>
                        Furthermore, an MA plan must automatically transfer a request to the standard timeframe if the MA plan denies a request for an expedited organization determination or an applicable integrated plan denies a request for an expedited integrated organization determination.
                        <SU>136</SU>
                        <FTREF/>
                         This step to automatically transfer expedited requests to the standard timeframe is consistent with Medicaid and CHIP managed care provisions listed in Tables E2, E3, and E4.
                    </P>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.570(d)(1) and 422.631(d)(2)(iv).
                        </P>
                    </FTNT>
                    <P>
                        As there are no existing CMS regulations imposing timeframes for state Medicaid FFS programs to provide notice of prior authorization decisions, in the proposed rule we specified that these programs must provide notice of such decisions as expeditiously as a patient's health condition requires, but no later than 72 hours for expedited requests and 7 calendar days for 
                        <PRTPAGE P="8879"/>
                        standard requests unless a shorter minimum timeframe is established under state law. For CHIP FFS, existing regulations require states to provide prior authorizations within 14 days or according to existing state law, in accordance with the medical needs of the beneficiary. Also, a possible extension of up to 14 days may be permitted if the beneficiary requests the extension or if the physician or health plan determines that additional information is needed.
                        <SU>137</SU>
                        <FTREF/>
                         To align with Medicaid, we are finalizing for CHIP FFS that beginning in 2026, states must provide notice of prior authorization decisions in accordance with the medical needs of the beneficiary, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination.
                    </P>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             
                            <E T="03">See</E>
                             42 CFR 457.495(d).
                        </P>
                    </FTNT>
                    <P>For Medicaid managed care plans and CHIP managed care entities, we proposed, and are now finalizing, to change the maximum permitted timeframe for the payer to send notices of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests beginning with the first rating period that starts on or after January 1, 2026. We are also finalizing requirements for Medicaid managed care plans and CHIP managed care entities concerning the timeframes for prior authorization of services (under 42 CFR 438.210 and 457.1230) but not the timeframes for issuing notices of other adverse benefit determinations and appeals under 42 CFR 438.404(c)(1) and (2) and 457.1260.</P>
                    <P>The provisions at 42 CFR 438.210(d)(2)(i) and 457.1230(d) require Medicaid managed care plans and CHIP managed care entities to make an expedited authorization decision no later than 72 hours after receipt of the request if the provider requesting the authorization indicates that following the standard timeframe could seriously jeopardize the beneficiary's life or health or ability to attain, maintain, or regain maximum function. If Medicaid managed care plans or CHIP managed care entities deny an expedited request, that request becomes standard and must be reviewed within 7 days.</P>
                    <P>
                        State law or managed care plan contracts may impose a shorter timeframe for these decisions in Medicaid and CHIP; the shorter timeframe would govern for state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities, as applicable.
                        <SU>138</SU>
                        <FTREF/>
                         If state law imposes a longer timeframe, payers must comply with Federal regulations within the shorter Federal timeframe—which will automatically make them compliant with their state regulations. For this reason, we are adding to the Medicaid managed care regulations at 42 CFR 438.210(d)(2)(i) and (d)(1), respectively, and CHIP managed care regulations at 42 CFR 457.1230(d), respectively, that the decision must be made as expeditiously as the enrollee's condition requires but no later than 72 hours in the case of expedited requests or 7 calendar days in the case of standard requests unless a shorter minimum timeframe is established under state law.
                    </P>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             In addition, States may, by contract, require applicable integrated plans to use shorter decision timeframes. 
                            <E T="03">See</E>
                             42 CFR 422.629(c).
                        </P>
                    </FTNT>
                    <P>State laws do not apply to MA plans, based on the preemption provision in section 1856(b) of the Act and at 42 CFR 422.402, which provides that the Federal standards established for MA plans supersede any state law or regulation, other than state licensing laws or state laws relating to plan solvency, with respect to the MA plans that are offered by MA organizations.</P>
                    <P>This final rule does not change the 72-hour timeframe required by current Federal regulations, or the authority for an extension of that timeframe, for expedited decisions made by MA organizations and applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities.</P>
                    <P>
                        For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe (87 FR 76297). If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the timeframe constitutes an adverse decision that may be appealed.
                        <SU>139</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5), and 457.1260(b)(3).
                        </P>
                    </FTNT>
                    <P>
                        The final rule does not change timeframes for prior authorization processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.
                        <SU>140</SU>
                        <FTREF/>
                         The current regulations for group health plans and group and individual market health insurance issuers adequately protect patient interests. QHP issuers on the FFEs are required to provide notification of a plan's benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests, which is consistent with the other CMS payers affected by this provision.
                    </P>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             
                            <E T="03">See</E>
                             45 CFR 147.136(b)(3).
                        </P>
                    </FTNT>
                    <P>We requested comments on the timeframe proposals and provide the summarized comments and responses here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters disagreed with the proposal to exclude QHP issuers on the FFEs from prior authorization shortened decision timeframe requirements and recommended that CMS reconsider the exclusion of these payers. Some commenters expressed concern that excluding QHP issuers on the FFEs from shorter prior authorization decision timeframe requirements would result in a negative effect on patient care. Commenters asserted that patients under these plans should be entitled to the same protections as others under this regulation. A commenter stated that they did not believe that shortening a QHP issuer on the FFEs' decision timeframe from the current 15-day response time for standard requests to 7 days would pose an undue burden. Another commenter encouraged CMS to work to align prior authorization notification requirements across all impacted payers as this could avoid confusion amongst patients and providers regarding whether a patient is covered by a QHP. Multiple commenters wrote that CMS should include QHP issuers on the FFEs in regulations requiring even shorter prior authorization decision timeframes: 24 hours for urgent or expedited requests and 72 hours for standard requests. A commenter recommended CMS impose a standard of 24 hours for expedited requests and 48 hours for standard requests and specified that this standard should apply to all payers, including those on the Exchanges. However, multiple commenters supported the 
                        <PRTPAGE P="8880"/>
                        proposal to leave in place the current prior authorization decision timeframes applicable to QHP issuers on the FFEs. These commenters raised general concerns about payer burden due to expedited timeframes and agreed specifically that applying expedited timeframes to QHP issuers on the FFEs could harm consumers by reducing participation by QHP issuers on the FFEs. A commenter recommended that timeframes be measured with business days as opposed to calendar days.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We discussed in the CMS Interoperability and Prior Authorization proposed rule the reasons why we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs. We did not propose and are not finalizing, any changes to prior authorization timeframes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.
                        <SU>141</SU>
                        <FTREF/>
                         We believe the current standard adequately protects patient interests. QHP issuers on the FFEs are required to provide notification of a plan's benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests; thus, QHP issuers on the FFEs have the same timeframe for expedited authorization decisions as other impacted payers in this final rule. For reasons discussed in this section, we are not finalizing any timeframes shorter than 72 hours for expedited requests for any impacted payers at this time. Additionally, the benefits for the patient of a shorter timeframe for standard prior authorization decisions should outweigh the additional burden that QHP issuers on the FFEs might experience, as compared to off-Exchange plans. Aligning timeframe requirements for prior authorization decisions across individual and group market plans would reduce the burden of compliance for QHP issuers on the FFEs for the proposed prior authorization requirements while continuing to protect consumer interests. Finally, making changes to regulations applicable to all non-grandfathered group and individual market plans or coverage for consistency with the proposed approach was outside the scope of the proposed rulemaking. While we are finalizing this rule as proposed, the prior authorization information that this final rule requires QHP issuers on the FFEs to publicly report per 45 CFR 156.223(c) will help provide insight into prior authorization timelines and practices that may support further improvements in the future.
                    </P>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             
                            <E T="03">See</E>
                             CFR 147.136(b)(3).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported the revised standard prior authorization decision timeframe of 7 calendar days, and many commenters supported the 72-hour decision timeframe for expedited prior authorization requests. Additionally, a commenter requested clarification on whether the 7-day standard decision timeframe would be calendar days or business days. A commenter recommended counting the turnaround time in business days rather than calendar days because processing prior authorization requests requires careful evaluation by payers and a review process that is dependent on working days as opposed to calendar days. Defining the turnaround timeframe by calendar days limits the time needed by payers to accurately reach a decision and is further reduced during holidays. This commenter suggested providing a timeframe that aligns with the number of working hours a payer has to evaluate a request and suggested CMS provide 7 business days. The commenter indicated that such an approach aligns with turnaround times for HIPAA transactions and would therefore prevent confusion over using both calendar days and business days. Another commenter recommended that the proposed standard be reduced from 7 days to 72 hours, stating that tracking timelines using hours instead of days will preclude any confusion or ambiguity regarding calendar days or business days.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We reiterate that current regulations are specific to using hours for expedited requests and we are not modifying the terminology for that requirement of 72 hours for expedited requests. For example, if a prior authorization request is submitted at 1:00 a.m. on Sunday, a response within 72 hours would mean by 1:00 a.m. on Wednesday. The regulations do not contemplate delays based on business hours or business days. For standard prior authorization requests, the current regulations (that is, before the amendments made by this final rule) for MA plans and Medicaid and CHIP managed care programs use the term “calendar days,” in recognition of health care services being agnostic of business days. The amendment we proposed and are finalizing for standard prior authorization decisions is “7 calendar days.” This final rule applies to the business process of the prior authorization request and decision, and not the transmission of the HIPAA standards when used for the request.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended having shorter decision timeframes that are less than 7 calendar days for standard prior authorization requests, ranging from 5 days, 72 hours, 48 hours, and 24 hours. Some commenters also suggested that decisions be made in real-time. In general, commenters recommended that CMS create faster prior authorization response timelines to improve the patient experience and access to care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are finalizing a requirement that prior authorization decisions be rendered as expeditiously as the patient's condition requires, but no later than 7 calendar days requires impacted payers to render their decision based on patient-specific information within 7 calendar days (or shorter if otherwise required via contract or state law) being the maximum. Further, as discussed in the proposed rule, we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and we believe the current standard adequately protects patient interests.
                        <SU>142</SU>
                        <FTREF/>
                         We will continue to review these comments and the supporting information to determine how we might incorporate such policies in future rulemaking as part of our ongoing mission to improve the patient and provider experience.
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             
                            <E T="03">See</E>
                             87 FR 76297.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Another commenter indicated that timely approvals for discharge to an appropriate setting of care are paramount to delivering high-quality care. The commenter explained that inappropriate and lengthy delays in payer responses to requests for transfers to post-acute care settings put patient care at risk. Specifically, the commenter explained that in nine percent of cases, the delay is caused by an untimely response from a payer. The commenter stated that while that percentage may seem low, it accounted for over 20,500 patient encounters across the commenter's system in 2022.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that timely response to such requests can impact patient care, and thus we are finalizing policies to reduce prior authorization decision timeframes. We also encourage payers to review their procedures for this and other similar cases to determine where process improvements would be 
                        <PRTPAGE P="8881"/>
                        appropriate to prevent such delays within their own organizations and provider relationships.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that ensuring appropriate review timeframes to make decisions for patients is critical to avoiding mistakes in care and that accelerated review timeframes increase the risk of failed or non-optimal therapies. A commenter wanted CMS to maintain the current 14-day decision timeframes for standard requests in Medicaid managed care. Another commenter suggested that CMS remove the proposal to shorten prior authorization turnaround timeframes until the Prior Authorization API is implemented and the agency can re-evaluate whether the policy is necessary and then re-issue a proposal. Multiple commenters had concerns about shortening the prior authorization timeframes. Several state commenters expressed concern that they will neither have the staffing capacity nor the operational efficiencies to implement the prior authorization timeframes by the compliance date. Some commenters noted that state legislative approval will be needed to increase state staffing or adjust vendor contracts, requiring additional time to implement. Some commenters also noted that states will need to evaluate and overhaul their entire prior authorization processes to attain the operational efficiencies needed to achieve the shortened decision timeframes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their concerns about accuracy in making decisions about prior authorizations, but that utilization management techniques and other professional safeguards are in place to mitigate such concerns. As we stated in the CMS Interoperability and Prior Authorization proposed rule, shorter prior authorization timeframes will improve patient care, reduce burden, and improve equity (87 FR 76297). The volume and substance of other comments support our proposals to shorten certain existing timeframes, and thus we are finalizing our proposal as described in this final rule. When the Prior Authorization API is implemented in 2027, this resource should further improve efficiencies in the process. We recognize the unique challenges some state commenters shared concerning the practical ability to implement the new prior authorization timeframes in state Medicaid and CHIP FFS by January 1, 2026. We understand that states often require longer timeframes to create new positions, adjust procurement arrangements, and rework system processes. We are willing to work with state Medicaid and CHIP FFS programs that may be unable to meet the new compliance date for the prior authorization timeframes. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframe requirements will be temporary and limited to the unique circumstances of the program.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that providers and health plans have multiple exchanges of information back and forth, including additional medical documentation and patient-specific information before a final determination. The commenter noted that the currently proposed decision timeframes do not account for these situations as most requests often require additional information from providers. The commenter also stated that these requirements, in combination with a lack of required information about the data content, could unintentionally increase the number of denials. Multiple commenters stated that shorter timeframes would mean an increase in staff and administrative resources and that without enough time there could be an increase in denials.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We also acknowledge that additional staff resources may be necessary. Firstly, the Prior Authorization API could mitigate communication and staffing issues, once it is fully implemented, but acknowledge that additional staff may be necessary during the implementation process. Also, the focus on process improvement overall may lead to improved efficiencies as payers address opportunities to reduce inefficiencies and meet the requirements of the final rule. Furthermore, the requirement to provide a specific reason for denials, regardless of the method of the prior authorization, should also support improvements in communication between health plans and providers. By making the documentation requirements clearer through the API, providers should submit more complete and appropriate documentation in the first submission, thus enabling quicker processing and fewer denials. Additionally, for Medicaid managed care plans at 42 CFR 438.210(d)(1) and for CHIP managed care entities through an existing cross reference at 42 CFR 457.1230(d), we are finalizing (with slight redesignations from current regulations) a provision that permits standard authorization decisions to have an extension of up to 14 additional calendar days (to the 7-calendar day timeframe) if the enrollee or the provider requests the extension or if the managed care plan justifies a need for additional information and how the extension is in the enrollee's interest. Medicaid managed care plans have been able to utilize a 14-calendar day extension since 42 CFR 438.210(d)(1) was first promulgated in 2001 (66 FR 43670). We believe this provides sufficient time for managed care plans and providers to complete the needed information exchange and enable the managed care plan to render its decision. Similarly for CHIP FFS, we are finalizing our policy at 42 CFR 457.495 to allow for a possible extension of up to 14 days if the enrollee requests the extension or if the physician or health plan determines that additional information is needed to furnish a prior authorization decision.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS convene a multi-stakeholder panel of health professionals and payer representatives to determine an appropriate timeframe for prior authorizations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do not agree that a multi-stakeholder panel of health professionals and payer representatives is necessary to determine an appropriate timeframe for prior authorizations. CMS has conducted surveys and listening sessions for nearly a decade, as have professional associations. Results are consistent for challenges of timeframes, with the consensus that this issue must be addressed. While some states have additional requirements for decision timeframes, they are not the same across the country. This final rule establishes policies for most of the programs over which CMS has authority to provide consistent and aligned structure for providers and payer communications on this important matter. To continue the conversation with another panel would further delay implementing these important changes that provide the opportunity for improving access to care and ensure that the industry collaborates on a solution to a critical problem that has widespread consensus. CMS will evaluate these reduced timeframes over time to see if future changes are needed, and may at that time conduct additional stakeholder meetings, but at this time we do not believe this is a necessary step to finalizing this policy, which will reduce timeframes and improve prior authorization processes across impacted payers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters requested clarification regarding the consequences and the available appeals process if payers do not meet decision timeframes. For example, a commenter 
                        <PRTPAGE P="8882"/>
                        stated that for cancer treatments, there should be no extensions unless a peer-to-peer review is needed, and if so, it should only be for 48 hours from the original request. Another commenter stated that policies should be implemented for payer oversight and dispute resolutions like targeted audits and penalties for violations. Multiple commenters highlighted that if decision timeframes are not met there should be a presumption of coverage for standard and pre-service determinations for providers and expedited appeal rights. A commenter noted that payers should be required to provide more information for denials when they do not meet decision timeframes and there should be civil monetary penalties on entities that demonstrate a statistical pattern of unnecessary documentation requests.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that data will be useful for oversight activities. The impacted payers are subject to the oversight and enforcement of the respective programs, in accordance with annual reporting, certification, and/or auditing. We have addressed program enforcement and compliance mechanisms in response to other similar comments in section I.D.2. of this final rule. For Medicaid managed care, 42 CFR 438.66(a) through (c) requires states to have a monitoring system for all of their managed care programs that addresses all aspects of the program and requires that data collected from these monitoring activities are used to improve program performance. Further, 42 CFR 438.66(e) requires states to complete an annual report on the performance of each of its managed care programs, submit that report to CMS, and post it on the state's website. CMS reviews these reports and can take enforcement action when needed. Along with the metrics published under 42 CFR 438.210(f), we will have broad visibility into the timeliness of Medicaid managed care plans' prior authorization decisions. For QHP issuers on the FFEs, penalties associated with failure to comply with deadlines or other provisions of 45 CFR 147.136 are generally within the purview of state regulators.
                        <SU>143</SU>
                        <FTREF/>
                         The AMA published a summary of some state initiatives regarding prior authorization practices.
                        <SU>144</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             Except to the extent that a state has deferred to CMS as the primary enforcer of these provisions or a state has entered into a Collaborative Enforcement Agreement (CEA) with CMS whereby the state attempts to obtain voluntary compliance but if unsuccessful, defers to CMS to handle enforcement.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             American Medical Association (2023, May 10). Bills in 30 states show momentum to fix prior authorization. Retrieved from 
                            <E T="03">https://www.ama-assn.org/practice-management/prior-authorization/bills-30-states-show-momentum-fix-prior-authorization.</E>
                        </P>
                    </FTNT>
                    <P>
                        For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule at 87 FR 76297, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. We do not believe it is practical to require payers to default to approval for prior authorization requests for which a timely response has not been provided. Therefore, impacted payers may choose to evaluate process improvements to meet the proposed timeframes and API in this final rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the deadline constitutes an adverse decision on the prior authorization request that may be appealed.
                        <SU>145</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5), and 457.1260(b)(3).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Operational Topics</HD>
                    <P>We solicited comments on what administrative, regulatory, technical, governance, operational, and workflow solutions would need to be addressed, for and by payers, to comply with the proposed timeframes for handling prior authorization review and approval activities. We also solicited comments on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 calendar days to 7 calendar days (for standard prior authorization requests) and from 72 hours to 1 day or 24 hours (for expedited prior authorization requests). We indicated that we wished to learn more about barriers that prevent payers from meeting shorter timeframes than those we proposed and requested input on whether MA organizations and applicable integrated plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities could provide notice of standard and expedited prior authorization decisions within shorter timeframes (for example, 5 calendar days and 48 hours, respectively), and if not, what issues and obstacles prevent that. We solicited comments on whether implementation of the Prior Authorization API could yield process improvements to support shorter decision timeframe requirements for prior authorization requests and on anticipated operational challenges of implementing the API that might affect a payer's ability to meet the proposed timeframes. Finally, we requested comments regarding the costs, benefits, and operational impact on providers and payers, as well as the impact on patients, of making and communicating prior authorization decisions on a shorter timeframe than those in the proposed rule. We received a substantial number of comments on these topics which will be useful as we consider future policies and guidance on these issues.</P>
                    <P>These policies for the impacted payers are being finalized in this final rule in the CFR sections listed in Table E4.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="575">
                        <PRTPAGE P="8883"/>
                        <GID>ER08FE24.005</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <PRTPAGE P="8884"/>
                    <P>
                        The timeframe for standard prior authorization requests and expedited organization determinations for certain programs may be extended for either 14 or 15 
                        <SU>146</SU>
                        <FTREF/>
                         days for reasons specified and permitted under existing or new policies. The specific citations are provided here for reference.
                    </P>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             QHP issuers on the FFEs follow 29 CFR 2560.503-1(f)(2)(iii)(A) for certain extensions. 
                            <E T="03">See</E>
                             29 CFR 2560.503-1(f)(2)(iii)(A).
                        </P>
                    </FTNT>
                    <P>• Medicaid FFS at 42 CFR 440.230(e)(1)(i). Timeframes for prior authorization decisions under the Medicaid FFS program have been newly established with this final rule. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension or if the state agency determines that additional information from the provider is needed to make a decision.</P>
                    <P>• MA expedited organization determinations at 42 CFR 422.572(b) and MA standard organization determinations at 42 CFR 422.568(b)(1)(i). Extensions are permitted for expedited and standard integrated organization determinations by applicable integrated plans (see 42 CFR 422.631(d)(2)(ii)).</P>
                    <P>• Medicaid managed care plan expedited authorization decisions at 42 CFR 438.210(d)(2)(ii) and Medicaid managed care plan standard authorization decisions at 42 CFR 438.210(d)(1)(ii). Extensions are permitted for expedited and standard prior authorization requests by up to 14 calendar days under certain circumstances.</P>
                    <P>• QHP issuers on the FFEs are permitted additional time on expedited requests under certain circumstances when a claimant does not provide sufficient information. See 29 CFR 2560.503-1(f)(2)(i). Limited extensions of the timeframe for standard requests are also allowed under certain circumstances. See 29 CFR 2560.503-1(f)(2)(iii)(A).</P>
                    <HD SOURCE="HD3">5. Requirements for Timing of Notifications Related to Prior Authorization Decisions</HD>
                    <P>This section outlines the regulatory amendments adopted in this rule as applicable based on other laws for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. These requirements also apply to most impacted payers. However, we did not address notifications from the QHP issuers on the FFEs for the same reasons we explained in section II.D.4. of this final rule.</P>
                    <HD SOURCE="HD3">a. Medicare Advantage Organizations</HD>
                    <P>MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which include decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we proposed to amend 42 CFR 422.568(b)(1) to require MA organizations to notify the enrollee of its prior authorization determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard organization determination for a medical item or service subject to the prior authorization rules at 42 CFR 422.122. We also proposed to move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) (regarding extensions of the adjudication timeframe for standard organization determinations) to 42 CFR 422.568(b)(2). We proposed to move the language previously at 42 CFR 422.568(b)(2) to a new paragraph (b)(3). We emphasized that this change to the regulation text structure would not change current requirements and that the proposed new 7-calendar day timeframe would remain subject to the existing standards and limits (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to when an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. For additional explanation on the continued applicability of existing standards, in this final rule, we are adding paragraph (a)(3) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. In this final rule we are also adding explanatory language to the beginning of paragraph (b)(1)(i) of 42 CFR 422.568; specifically, we are adding the phrase “For a service or item not subject to the prior authorization rules at § 422.122” to the beginning of the sentence to be clear that those requests not subject to the prior authorization rules at 42 CFR 422.122 will be adjudicated under the existing 14-calendar day timeframe, such as a request for a supplemental benefit that involves an OTC drug or a pre-service request made by an enrollee who is seeking an advance determination on an item or service that is not subject to prior authorization under the rules at 42 CFR 422.122. In contrast, 42 CFR 422.568(b)(1)(ii) sets forth the 7-calendar day timeframe for those requests for a service or item that are subject to the prior authorization rules at 42 CFR 422.122.</P>
                    <P>We proposed similar amendments to the integrated organization determination requirements at 42 CFR 422.631 for applicable integrated plans. We are making in this final rule explanatory revisions to the regulation text at 42 CFR 422.631 consistent with the revisions made at 42 CFR 422.568 and amended 42 CFR 422.631(d)(2)(i)(B) to state that when a provider makes a request for an item or service, the applicable integrated plan must notify the enrollee of its determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard pre-service organization determination that is subject to 42 CFR 422.122. We also proposed an amendment to 42 CFR 422.631(d)(2)(iv)(B) to state that when an applicable integrated plan denies a request for an expedited determination and automatically transfers the request to the standard timeframe, it must make its determination within the applicable timeframe established at 42 CFR 422.631(d)(2)(i)(B). This means that for prior authorization requests within the scope of 42 CFR 422.122, the 7-calendar day timeframe applies, rather than the current 14-calendar day timeframe for an integrated organization determination. These changes also apply to applicable integrated plans that are MCOs as defined at 42 CFR 438.2, because per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans. These amendments are consistent with changes for other Medicaid managed care plans being finalized at 42 CFR 438.210(d)(1) and (2). Concerning MA organizations (including applicable integrated plans), our proposal was limited to the timeframes for standard determinations involving prior authorization, and there are no changes to the timeline for expedited integrated organization determinations, extensions, or the requirements for notice to enrollees.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter urged CMS to require that any failure by an MA plan or applicable integrated plan to provide notice of an organization determination within the same timeframes (and without having requested an extension) constitute a deemed denial for which the provider may request a reconsideration by an independent reviewer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge this commenter's concern about the failure of MA plans to provide notice within 
                        <PRTPAGE P="8885"/>
                        the required timeframes. Under the existing MA rules, a failure to meet the deadline by which an organization determination, including a request for prior authorization, constitutes a denial that can be appealed to the next level (reconsideration by the MA organization). See 42 CFR 422.568(f) and 422.631(d)(1)(ii). The MA program regulations (42 CFR 422.592 through 422.596 and 422.634) provide for review by an Independent Review Entity (IRE) after an MA organization's adverse reconsidered organization determination, including where the MA organization fails to issue a reconsidered organization determination in a timely fashion. We did not propose, and are therefore not finalizing here, an amendment to those rules to escalate prior authorization denials to the IRE. However, the existing regulations at 42 CFR 422.590(h)(1) and 422.629(k)(4) provide that for reconsiderations by MA plans and applicable integrated plans, the individuals who make the reconsideration determination must not have been involved in the organization determination. We also reiterate that providers should follow up on the status of a request with the payer. Failure to respond to a request for the status of the pending prior authorization request does not constitute a denial (unless the lack of response continues beyond the deadline for response) but may indicate other issues in the process such that an appeal may not be necessary. We acknowledge that issues in communication between payers and providers may continue to exist, and encourage providers to notify payers or CMS of any patterns for poor communication and untimely issuance of prior authorization decisions.
                    </P>
                    <HD SOURCE="HD3">b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings</HD>
                    <P>For the Medicaid FFS program, we proposed, in the CFR sections listed in Table E2, regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. We stated that the new requirements would apply to prior authorization decisions beginning January 1, 2026. We are finalizing that policy in this final rule.</P>
                    <P>Under the new requirement for Medicaid FFS, which appears at 42 CFR 440.230(e)(1), notice of the state Medicaid program's decision regarding an expedited request for prior authorization will have to be communicated as expeditiously as a beneficiary's health condition requires, but no later than 72 hours after receiving a provider's request for an expedited determination, unless a shorter minimum timeframe is established under state law. Notice of a decision on a standard request for prior authorization will have to be communicated to the requesting provider as expeditiously as a beneficiary's health condition requires, but no later than 7 calendar days after receiving the request, unless a shorter minimum timeframe is established under state law. If the state determines that it needs additional information from a provider to make a decision, or if the beneficiary or provider requests an extension, the proposed decision-making and communication timeframe for a standard request may be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the state agency determines that additional information from the provider is needed to make a decision. Such extensions may be justified and in the beneficiary's interest if medical evidence from outside providers is needed to support the request, or if there are other circumstances identified by either the provider or the beneficiary.</P>
                    <P>Independent of this final rule's API proposals and their application to Medicaid prior authorization requests, Medicaid has longstanding beneficiary notice and fair hearing regulations. CMS has interpreted these existing regulations to apply to prior authorization requests for Medicaid FFS and will continue to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, in concert with other provisions of this final rule, including the Prior Authorization API.</P>
                    <P>As discussed in detail in the proposed rule (87 FR 76299 and 76300), the current Medicaid notice and fair hearing regulations at 42 CFR 435.917 and 42 CFR part 431, subpart E, apply to all prior authorization decisions. Therefore, states are required to—</P>
                    <P>• Provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary's prior authorization request;</P>
                    <P>• Include the content described at 42 CFR 435.917 and at 42 CFR part 431, subpart E, including information about the beneficiary's right to request a fair hearing to appeal the partial or total denial, in the beneficiary notice when a state denies the prior authorization request in whole or in part;</P>
                    <P>• Provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim, which includes prior authorization requests, with reasonable promptness; and</P>
                    <P>• Provide at least 10-day advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization, including information regarding the beneficiary's right to request a fair hearing.</P>
                    <P>These notice and fair hearing requirements are not affected by any of the changes made elsewhere in this final rule. As noted in the CMS Interoperability and Prior Authorization proposed rule, the Medicaid notice requirements are separate from and independent of, the new timeline for provider notice that is finalized at 42 CFR 440.230(e)(1).</P>
                    <P>To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, we proposed several updates to the existing regulations at 42 CFR 431.201, 431.220, and 435.917, and a new 42 CFR 440.230(e)(2). The proposed changes are intended to further explain, but not change, Medicaid notice or fair hearing policy or operational requirements for states. We proposed and are finalizing, with one exception discussed below, that the changes referenced in this paragraph take effect on the effective date of the final rule. Please see 87 FR 76300 for the detailed text. The regulations and amendments are listed in Table E3.</P>
                    <P>The proposed changes for 42 CFR 431.201 included replacing the term “beneficiary” with “enrollee” in the revised definition of “Action.” This change was proposed in error, and the preamble to the CMS Interoperability and Prior Authorization proposed rule did not discuss the potential impact of changing “beneficiary” to “enrollee” on the definition of “Action.” In this final rule, we are reverting to the term “beneficiary” in the definition of “Action” at 42 CFR 431.201, consistent with the current definition and with our stated intent in the proposed rule that the changes would not change Medicaid notice or fair hearing policy or operational requirements for states.</P>
                    <P>We received comments on fair hearings and provide those and our responses here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for our proposal to further explain the application of Medicaid notice and fair hearing requirements to Medicaid FFS prior authorization decisions and recommended that the proposed changes be codified. A few commenters noted that states already apply notice and fair hearing requirements to Medicaid FFS prior authorizations. 
                        <PRTPAGE P="8886"/>
                        Multiple commenters noted that Medicaid agencies already have provider hearing rights for prior authorization decisions in place.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' support for the proposed updates to the Medicaid notice and fair hearing regulations, which we are finalizing as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters noted that patients should receive equitable fair hearing rights for their prior authorizations, regardless of whether they are enrolled in a Medicaid FFS or a managed care plan. A few commenters expressed support for the proposed changes which would explain that Medicaid FFS notice and fair hearing requirements are consistent with current regulations for notice and appeal rights for managed care prior authorization decisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that comparable and aligned notice and fair hearing rights should apply across delivery systems. As discussed in the CMS Interoperability and Prior Authorization proposed rule, we have historically interpreted the existing Medicaid notice and fair hearing regulations to apply to prior authorization requests for Medicaid FFS. Given the alignment between these state-level requirements and the managed care plan-level requirements, equitable notice and appeal rights have been and will continue to be available to Medicaid FFS and managed care beneficiaries and that the updates, which we are finalizing as proposed, will further strengthen the existing alignment between delivery systems regarding notices and fair hearings/appeals.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that there needs to be more clarification in the rule that existing Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. Another commenter recommended CMS mandate more details on the hearing process to ensure that a hearing can be conducted expeditiously and objectively. A commenter recommended that the language in the regulation be strengthened to explicitly state that failure to act on a request for prior authorization will give rise to notice and hearing rights.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The updates we are making to these regulations, which we are finalizing as proposed, provide additional details regarding how Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. These changes provide further detail about, but do not change, the current application of these regulations to Medicaid FFS prior authorization decisions. Therefore, the existing requirements for the fair hearing process at 42 CFR part 431, subpart E, apply to Medicaid FFS prior authorization fair hearings. These include a requirement that fair hearings must be conducted by an impartial person who was not directly involved in the initial decision (42 CFR 431.240(a)(3)) and requirements for when the state must take final administrative action on a fair hearing request (42 CFR 431.244(f)). These regulations also require the state to provide notice to a beneficiary (42 CFR 431.206(c)(2)) whenever a hearing is required in accordance with 42 CFR 431.220(a), which includes when the state fails to act upon a claim, including a prior authorization decision, with reasonable promptness.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS expand on proposed 42 CFR 440.230(e)(2) to require written notice of a prior authorization decision be provided to the provider as well as the beneficiary.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The Medicaid notice and fair hearing provisions at 42 CFR 435.917 and 42 CFR part 431, subpart E, which are cross referenced at 42 CFR 440.230(e)(2), apply to applicants and beneficiaries, not providers. Therefore, we decline this recommendation and will finalize 42 CFR 440.230(e)(2) as proposed. There are separate requirements regarding provider notification of prior authorization decisions. As stated in this final rule, we are finalizing requirements for payers to provide a specific reason for denials, as well as the status of a prior authorization, either through the Prior Authorization API as specified, or through existing processes. When providing a status for a prior authorization, the response must indicate whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or the payer may request more information from the provider to support the prior authorization request.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter raised concerns about whether and how notice and appeal rights can be provided electronically and noted that lower-income consumers may have inconsistent access to electronic communications. This commenter recommended that HHS continue to require a redundant written notice for all important Medicaid notices, including those related to prior authorization.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The provision of electronic notices to Medicaid applicants and beneficiaries is addressed at 42 CFR 435.918. Individuals must be provided a choice to receive notices in electronic format or by regular mail and have the option to request that all electronic notices also be provided by regular mail. Changes to 42 CFR 435.918 are outside the scope of this rule. The Medicaid notice requirements, which include the provision of fair hearing rights, will continue to apply unchanged when API-based notifications begin. Therefore, low-income beneficiaries enrolled in Medicaid will continue to receive notices by mail, electronically, or both, even after the API-based notifications begin.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed that CMS's proposal to make explicit the requirement for a fair hearing to appeal prior authorization non-compliance is inadequate to address prevalent and profitable wrongful denials of prior authorization. This commenter stated that very few patients can appeal wrongful denials and rarely do appeal and noted that medical practices aren't compensated for prior authorizations or appeals, which harms patients as well.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Fair hearings are an important part of a beneficiary's due process rights. While fair hearings cannot directly prevent inappropriate denials of prior authorization requests, they do provide a pathway for a beneficiary to remedy an inappropriate prior authorization denial, termination, or reduction and provide data to states to help them identify problems with the prior authorization process. We believe that improvements in the process overall will occur by using the API once that is in place, as providers will have additional information on which to base the submission of an initial prior authorization request.
                    </P>
                    <HD SOURCE="HD3">c. Medicaid Managed Care</HD>
                    <P>
                        For Medicaid managed care, we proposed new timeframes for notice of decisions on standard (non-expedited) prior authorization requests which would apply beginning with the rating period that starts on or after January 1, 2026, and proposed to revise 42 CFR 438.210(d)(1) and (2) to accomplish this. Specifically, we proposed to revise 42 CFR 438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1, 2026, managed care plans must provide notice of standard authorization decisions as expeditiously as the enrollee's health condition requires and within state-established timeframes that may not exceed 7 calendar days following the plan's receipt of the request for service. Our proposed amendment provided that for rating periods that begin before January 1, 2026, the current rule would 
                        <PRTPAGE P="8887"/>
                        remain in effect. We proposed to specify the standard authorization requirements by the compliance dates by leaving the section header “Standard authorization decisions” as 42 CFR 438.210(d)(1) and redesignating standard authorization timeframes as 42 CFR 438.210(d)(1)(i)(A) and (B). We also proposed to move the current regulation text on extending the prior authorization decision timeframe from 42 CFR 438.210(d)(1)(i) and (ii) to 42 CFR 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. We explained that our proposal would not change the current provisions for how failure to issue a decision within the required timeframe constitutes an adverse benefit determination that can be appealed under 42 CFR 438.404(c)(5). The regulations at 42 CFR 438.404 and other regulations governing appeal rights at 42 CFR part 438, subpart F, would continue to apply and we did not propose to amend those regulations. We note that 42 CFR 438.404(c)(3) through (6) provide that certain adverse benefit determinations must be issued on the timing specified at 42 CFR 422.210(d); the new timeframes proposed (and finalized) in this rulemaking will apply to those specific adverse benefit determinations. In addition, under current regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs; nothing in this rulemaking would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined at 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) applied to those plans.
                    </P>
                    <P>We received a few comments on this subject and provide our responses to those here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter agreed with the proposal to provide notice of decisions for standard prior authorization requests within state established timeframes not exceeding 7 calendar days, and another commenter disagreed with the proposal to shorten the maximum amount of time for Medicaid managed care plans to respond with a decision from 14 to 7 days. Another commenter proposed that the standard should be 24 hours or less for standard requests. A commenter stated that Medicaid and CHIP managed care programs already have requirements to issue prior authorization decisions within a certain timeframe established by the state and that those standards provide adequate protection for enrollees and providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As we stated in the proposed rule, and based on CMS and other industry studies on the impact of delays to patient health or access to care from extended authorizations, reducing standard prior authorization decision timeframes from 14 calendar days to 7 calendar days should improve patient care outcomes and ensure that patients have more timely access to services (87 FR 76296).
                    </P>
                    <HD SOURCE="HD3">d. CHIP Fee-for-Service and Managed Care</HD>
                    <P>To implement the proposed prior authorization timeframes for CHIP, we proposed to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP FFS and managed care programs. These changes are listed in Table E2. We proposed that beginning on January 1, 2026, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and 72 hours after receiving the request for an expedited determination, unless an alternative option is preferred by industry based on public comments. Further, we stated that if a beneficiary requests an extension of a prior authorization review, or if the provider or health plan determines that additional information is needed for such review, an extension of up to 14 calendar days may be granted. We proposed to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent than our proposal, states would be allowed to apply and enforce those shorter timeframes for prior authorization responses. Timely prior authorization decisions are important patient protections, and CHIP patients should be afforded the same decision timeframes as Medicaid and Medicare patients.</P>
                    <P>Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a beneficiary has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We did not propose any changes to this requirement, as it already applies to decisions related to the prior authorization of services.</P>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule we explained that overall, we believed that the decision and notification timeframes proposed for certain impacted payers would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. Introducing prior authorization decision timeframes that are the same across these impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and thus may make more time available for providers to render patient-centered care.</P>
                    <P>Currently, CHIP managed care program regulations reference the Medicaid managed care regulations for the timelines and requirements for CHIP managed care entities as to prior authorization decisions and notices as well as appeal processes. We explained in the proposed rule that the proposal to amend 42 CFR 438.210(d) for timeframes would also apply to standard and expedited decisions made by CHIP managed care entities because of the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d). We did not propose to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we proposed to amend 42 CFR 438.210(d)(2)(i) to explain that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. We did not propose any changes to the authority for a 14-calendar day decision timeframe provided at 42 CFR 438.210(d)(2)(ii).</P>
                    <P>We received the following comments related to CHIP FFS and managed care and include our responses to those comments here.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter disagreed with CMS's proposal to shorten the maximum amount of time for CHIP FFS and managed care to respond with a decision from 14 to 7 days. The commenter proposed that the standard should be 24 hours or less. Another commenter recommended CMS provide equal protection for children enrolled in CHIP FFS against unnecessary delays in accessing necessary services due to prior authorization procedures. The commenter also recommended that state CHIP agencies follow the same rules as state Medicaid agencies, including specific timelines for prior authorization responses for outpatient prescription drugs. Another commenter expressed their support for aligning the beneficiary protections in CHIP and Medicaid 
                        <PRTPAGE P="8888"/>
                        managed care and recommended CMS maintain 42 CFR 457.1230(d) as proposed, applying 42 CFR 438.210 to CHIP managed care entities with the proposed shorter timelines for responses to standard requests for prior authorization, characterizing these as stronger beneficiary protections.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Though we anticipate the Prior Authorization API will introduce additional efficiencies into the prior authorization process, we are uncertain that such a truncated standard decision timeframe would be possible until we have completed further data collection and analysis after the implementation of the API. The recommendation concerning CHIP prior authorization decision timeframes for outpatient prescription drugs is outside the scope of the final rule. We agree with comments that recommend CHIP prior authorization decision timeframes be in alignment with Medicaid.
                    </P>
                    <P>We are finalizing the proposals to adopt the timeframes we proposed for responses by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to prior authorization requests. We are not requiring that impacted payers approve a request for prior authorization if that payer fails to meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. The 72-hour requirement for expedited requests is measured in hours, whereas the 7-day requirement for standard requests is measured in calendar days. In the case of expedited and standard requests, the timeframes are 72 hours and 7 days, respectively, unless a shorter minimum timeframe is established under state law.</P>
                    <P>Tables E2 and E3 provide a list of some, but not all of the final policies for decision notification timelines for the impacted payers. The full list of final policies and citations is included in Table E4 at the end of this section. We included these tables for ease of reference for the narrative on the discussion of notifications and timeframes.</P>
                    <P>Table E3 is specific to the Medicaid FFS notice and fair hearings provisions, which provide an important service to beneficiaries and providers alike. This rule finalizes modifications to those provisions, and this table and accompanying narrative provide the reader with citations to new and existing provisions.</P>
                    <GPH SPAN="3" DEEP="278">
                        <GID>ER08FE24.006</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="169">
                        <PRTPAGE P="8889"/>
                        <GID>ER08FE24.007</GID>
                    </GPH>
                    <HD SOURCE="HD3">6. Extensions, Exemptions, and Exceptions</HD>
                    <P>See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Prior Authorization API for state Medicaid and CHIP FFS programs and exceptions for the Prior Authorization API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 87 FR 76279).</P>
                    <HD SOURCE="HD3">7. Public Reporting Requirements for Prior Authorization Metrics</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule we discussed the importance of accountability for payer prior authorization practices and proposed that certain data be made publicly available for patients and providers to better understand the types of items and services which required prior authorization and how each payer performed over time for approvals and denials. We are finalizing our proposal to require impacted payers to report certain aggregated metrics about prior authorization by posting them on the payer's website. This requirement underscores the importance of transparency and accountability in the health care system. Public disclosure of the items and services which are subject to prior authorization, as well as organizational performance, offers useful information to providers, patients, and other interested parties. Performance data could allow for objective evaluation of the efficiency of prior authorization practices of each organization, and it enables payers to assess trends, identify areas for improvement, and work towards continuous process improvement while maintaining necessary quality checks for quality and appropriateness of care.</P>
                    <P>We are finalizing as proposed that state Medicaid and CHIP FFS programs will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level. We are finalizing a modification to our proposal for reporting to be at the organization level to require that reporting be at the contract level for MA organizations as discussed in this section (section II.D.7. of this final rule). Additionally, we explain that integrated plans will report items and services covered by MA organizations at the MA contract level and items and services covered by Medicaid managed care plans at the plan level as the separate requirements for MA organizations and Medicaid managed care plans will apply under the respective contracts.</P>
                    <P>We described how payers might use the information for process improvements and performance analysis in the proposed rule (87 FR 76304). For example, an impacted payer could use these data to examine its performance trends. In addition, we explained how providing this information publicly would benefit patients (who could use the information when selecting among plan or organization options) and providers (in when and whether to contract with an impacted payer). The legal authority for requiring such public reporting is discussed in section II.D.10. of this final rule.</P>
                    <P>We are finalizing our proposal that for each metric listed, data would be reported in aggregate for all items and services. We received many comments on the proposed public reporting of metrics, the timing, and the level of reporting. The suggestions were detailed and represented diverse issues and concerns from interested parties about prior authorization challenges and potential uses for the data. CMS will use the comments received as CMS considers future policy development. We intend to support transparency and accountability and enable patients to access data that are meaningful and easy to use for decision-making and understanding the prior authorization processes. The metrics we are finalizing represent the most significant issues for both patients and providers identified over the past decade on a national level, including the CMS listening sessions referenced at the beginning of this section. Furthermore, payers can supplement the information they report with additional metrics on prior authorization. We may consider additional reporting options in the future. We reiterate that the prior authorization reporting metrics are on medical items and services, excluding drugs covered by the impacted payers.</P>
                    <P>We are finalizing the requirement for impacted payers to make reports available annually on all of the following:</P>
                    <P>• A list of all items and services that require prior authorization.</P>
                    <P>• The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                    <P>• The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                    <P>• The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                    <P>• The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                    <P>• The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                    <P>• The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                    <P>
                        • The average and median time that elapsed between the submission of a 
                        <PRTPAGE P="8890"/>
                        request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services.
                    </P>
                    <P>• The average and median time that elapsed between the submission of a request and a decision by the payer, plan, or issuer, for expedited prior authorizations, aggregated for all items and services.</P>
                    <HD SOURCE="HD3">a. Reporting Prior Authorization Metrics</HD>
                    <P>As described previously, we proposed to require impacted payers to report certain metrics to support a level of accountability for the requirements in this final rule. As discussed previously, public disclosure of information for each audience—patients, providers, and the general public—supports the intent of this final rule to improve the prior authorization process, patient care, and burden reduction.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported CMS's efforts to promote transparency through public reporting of these aggregated metrics. These commenters believe such reporting will increase transparency from payers related to the volume of prior authorizations. For example, a commenter wrote to encourage CMS to propose in future rulemaking to use the prior authorization data the agency would collect from impacted payers to help develop quality measures to incorporate into quality ratings across certain payer programs, specifically for MA organizations. This would ensure that such data are incorporated more directly into a consumer-friendly comparison tool so that payers' prior authorization practices are available to physicians and practitioners, including gastroenterologists, to ensure transparency and accountability in the prior authorization process. Multiple commenters stated that reporting metrics could be informative to providers in the context of what they submit to payers for prior authorization requests, as the data might provide insights about the types of services that are approved or denied. A commenter noted that prior authorization metrics could be useful to patients as they decide which health plans to select, and another commenter appreciated that CMS's proposal aimed to strike a balance between data reporting burden and providing meaningful data to consumers and providers. Another commenter supported reporting prior authorization metrics on the payer's website by March 31, 2026. Some commenters believed that CMS should require public reporting of the metrics sooner than proposed, and multiple commenters recommended that CMS require the public reporting requirement immediately upon finalizing the rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support of our proposed prior authorization reporting metrics, including those commenters who recommended that CMS consider additional future uses for the data for other program purposes and require compliance as soon as the rule is finalized. We agree that payers have the data available now, as they are currently conducting the prior authorization process, and that the data would provide a baseline for reporting. As proposed and finalized, CMS is not collecting these data, but instead requiring impacted payers to post such data on the payer's website. We encourage payers to consider developing and posting reports of these metrics at the earliest date feasible. We are finalizing the requirements for public reporting as well as the compliance dates in 2026, as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS require payers to report prior authorization data at a more granular level. Specifically, multiple commenters recommended that CMS require MA organizations to report prior authorization metrics at the plan level or state level. Commenters stated that the organization level for MA organizations was a higher level of aggregation than the plan level for Medicaid managed care plans and CHIP managed care entities and therefore would not present the same level of detail. Those commenters pointed out that MA organization metrics reported at the organization level would not be useful to consumers choosing plans in their area. Other commenters suggested more discrete reporting levels, including county level, specialty/benefit level, or service level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Upon further consideration and taking the comments into account, we determined that contract level is the more appropriate reporting level for MA organizations. MA organizations generally have multiple plans under the same contract as it is common throughout the industry to offer a variety of plans within a service area. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) (that is, the various MA plans) offered under an individual contract; these data are specific to the contract to which they correspond. CMS already requires MA organizations to report some contract-level data about their organization determinations to the agency on an annual basis and Star Ratings are assigned at the contract level. While this particular provision does not require MA organizations to submit data to CMS, a consistent approach of contract-level reporting in the MA program will give consumers useful information while limiting plan burden. By requiring contract-level reporting for these data, we ensure that the format of this reported data remains consistent with that of other similar data that MA organizations are required to report.
                    </P>
                    <P>We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the plan level will allow beneficiaries and states to compare plans within the state. Requiring QHP issuers on the FFEs to report at the issuer level, aggregating plans under their purview, is consistent with their reporting on quality improvement strategies as described in section 1311(g) of the Affordable Care Act (45 CFR 156.1130), which provides consistency with other QHP reporting requirements.</P>
                    <P>While we understand the desire from some commenters to increase the level of granularity for reporting, we have concerns about data overload, patient understanding, and usability of the data. For example, reporting at the specialty level and service level could be overwhelming because of the volume of information presented. A patient might not be able to relate to the data and would not refer to the reports as intended. There can and should be both transparency and accountability in the information that is presented to the public and we will continue to explore opportunities to strike the appropriate balance with impacted payers. We are finalizing a modification to our proposal for MA organizations to report at the contract level. We are finalizing, as proposed, that state Medicaid and CHIP FFS programs will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level.</P>
                    <P>We may assess whether to collect more detailed metrics than we are finalizing here in program-specific rulemaking in the future. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial to require more detailed data, the state may require additional metrics in its managed care contracts.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested clarification on whether integrated care plans for dually eligible individuals, such as FIDE SNPs, should report these data consistent with MA organizations, at the contract level, or consistent with 
                        <PRTPAGE P="8891"/>
                        Medicaid managed care plans, at the plan level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Integrated care plans generally combine D-SNPs, which include FIDE SNPs and HIDE SNPs—both as defined at 42 CFR 422.2—and Medicaid managed care plans offered by the same parent organization. D-SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. In these arrangements, there is an MA organization with a contract with CMS for the MA D-SNP and an organization with a contact with the state for the Medicaid managed care plan.
                    </P>
                    <P>For items and services that require prior authorization under an integrated plan's MA benefit package, data must be reported in a manner consistent with the requirements for MA organizations, which we are finalizing at the contract level. In the case of integrated care, the affiliated Medicaid managed care plan will report prior authorizations of items and services covered under the plan's Medicaid benefit package at the plan level. Where there is not a clear delineation between whether items or services are covered under Medicare or Medicaid (for example, home health services), we will accept any reasonable methodology for attributing the prior authorization reporting to one payer versus the other.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended a more phased-in approach to the reporting of prior authorization metrics. A commenter stated that while prior authorization metrics should not be publicly reported until after the electronic FHIR APIs have been implemented, the prior authorization metrics should still be reported to CMS beginning March 2026. A commenter recommended that CMS begin to phase in reporting requirements before the 2026 implementation period (for example, require payers to report some, but not all, metrics soon after the rule is finalized) to help identify any issues with the reporting process so that they can be addressed timely.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree that a phased-in approach to reporting metrics is necessary given that payers already conduct prior authorization processes and likely already track data for many of the metrics for their usual business operations. We are finalizing compliance dates in 2026, as stated previously. We agree that reporting prior authorization metrics conducted using the Prior Authorization API will not be reported until after the Prior Authorization API has been implemented, and that the technology could be capable of supporting automated reporting on its use. The metrics to be included in the reports beginning in March 2026 will be based on an impacted payer's current prior authorization processes, in advance of implementation of the Prior Authorization API. Reporting information about performance data in advance of implementation could provide valuable data in the years post-implementation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concerns about how the prior authorization metrics could be used by payers in inappropriate or harmful ways to providers. A commenter flagged that the publicly reported metrics could lead to plans “self-selecting” patients by implementing other burdensome prior authorization processes to avoid approving services, which could lead to patients who need those services enrolling in other plans. Another commenter recommended that CMS address steps it will take to protect against adverse selection. This commenter urged CMS to consider how it will mitigate unintended consequences that may occur as competing payers decide to analyze each other's data once it becomes public. The commenter wrote that CMS should make clear that any such practices would be against the spirit and intent of the reporting requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge concerns by a few commenters that prior authorization policies and information on the publicly reported metrics could technically be used inappropriately for improper decision-making purposes or other reasons. Public reporting does not in and of itself create such behavior. However, we believe requiring that public availability of prior authorization metrics will have the opposite effect; that is, payers will use the data to try to improve their performance to improve their competitive standing in a program.
                    </P>
                    <P>In addition, there are some safeguards in place to help address the concerns raised by commenters about inappropriate efforts to discourage enrollment by individuals who need certain covered services. Medicaid managed care regulations also provide significant patient protections for access to covered services at 42 CFR 438.206 through 438.210. For example, 42 CFR 438.210(a) requires states' contracts with Medicaid managed care plans to identify, define, and specify the amount, duration, and scope of each service covered by the plan and such amount, duration, and scope must be no less than that furnished to Medicaid FFS beneficiaries. Existing regulations at 42 CFR 438.66 require states to have a monitoring system that addresses all aspects of each Medicaid managed care program and to use the data collected from their monitoring activities to improve the performance of their managed care program, including at a minimum enrollment and disenrollment trends in each managed care plan. Additionally, 42 CFR 438.66(e) requires states to submit to CMS a report on each of their Medicaid managed care programs that provides information on and an assessment of the operation of the managed care program.</P>
                    <P>Further, section 1852(b)(1) of the Act prohibits discrimination by MA organizations on the basis of health status-related factors and directs that CMS may not approve an MA plan if CMS determines that the design of the plan and its benefits are likely to substantially discourage enrollment by certain MA eligible individuals. In addition, MA organizations must comply with applicable Federal civil rights laws that prohibit discrimination on the basis of race, color, national origin, sex, age, or disability, including section 1557 of the Affordable Care Act, Title VI of the Civil Rights Act of 1964, section 504 of the Rehabilitation Act of 1973, and the Age Discrimination Act of 1975. The regulation at 42 CFR 422.110 provides that an MA organization may not deny, limit, or condition the coverage or furnishing of benefits to individuals eligible to enroll in an MA plan offered by the organization on the basis of any factor that is related to health status. MA organizations discouraging or preventing enrollment in an MA plan by beneficiaries by implementing burdensome prior authorization processes to avoid approving services would be prohibited by 42 CFR 422.110. CMS relies on the MA anti-discrimination provision; the agency's authority under section 1856(b) of the Act to adopt standards for MA organizations; and the agency's authority under section 1857(e) of the Act to add terms and conditions that are necessary, appropriate, and not inconsistent with the Medicare statute. CMS does not collect detailed information on prior authorization policies as part of the bid. However, CMS will continue to monitor for potential discrimination by plans through prior authorization and other utilization management programs in our review of complaints received from beneficiaries and providers and will take action, as necessary. CMS may also consider future sub-regulatory guidance based on a review of complaints.</P>
                    <P>
                        We also believe that MA and other managed care plans will use the published data to drive performance 
                        <PRTPAGE P="8892"/>
                        improvement to facilitate provider network development and that providers will use the prior authorization metrics to evaluate managed care plans and make decisions on whether to join or remain part of a plan's network.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that if CMS intends to require public reporting in the final rule, CMS should explain how the data would benefit interested parties and conduct education and outreach to prevent confusion or misinterpretation of data. Multiple commenters stated their hesitation to require public reporting of prior authorization data without understanding the purpose of the reporting, and another recommended that CMS reevaluate the need and value of payers reporting the prior authorization metrics versus its costs and resource burden. Multiple commenters highlighted the significant new administrative burden that reporting prior authorization metrics would cause. Other commenters recommended that CMS remove the proposed requirement for payers to publicly report prior authorization metrics.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are aware that payers have many reporting requirements for state and Federal programs and that preparing these public disclosures may require additional effort. Payers also provide educational resources to patients and providers for enrollment, directories, and other health care reminders—all to explain benefits and services and improve the health care experience. We are finalizing policies in this final rule to address longstanding, important process challenges related to prior authorization. Reporting on these metrics, including, for example, the services that require prior authorizations, the number of denials, those approved, and those overturned after appeal, will give the patients and providers a better understanding of payer performance in those categories—and over time—of the changes in performance in those categories. These data will demonstrate the intended impact of these policies. Public reporting is one of the most universal, effective means to demonstrate improvement or change. This public reporting has value because it can provide a benchmark for patients or providers to understand, at a high level, the volume of services a payer approves or denies, the types of services it authorizes, or changes in those decisions over time. Not all patients will use or necessarily understand all of the data, but it may help support the beginning of a conversation between either the patient and the payer, or the patient and the provider. We anticipate payers will identify the most appropriate locations on their website for the information to be public. We additionally note that the Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy.
                        <SU>147</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             Centers for Medicare and Medicaid Services (2023, September 15). Prior Authorization and Pre-Claim Review Initiatives. Retrieved from 
                            <E T="03">https://www.cms.gov/data-research/monitoring-programs/medicare-fee-service-compliance-programs/prior-authorization-and-pre-claim-review-initiatives.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that a voluntary consensus SDO should develop standardized codes that could be used to document prior authorization denial reasons. Then, CMS could revise the metrics to include information on the reason for denial to provide a more complete picture of a plan's prior authorization process.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed previously in the section on providing a reason for denial, the standard codes for denial reasons are an external code set maintained by X12, which is a voluntary SDO. Any organization or individual interested in providing updates to this code set may do so by submitting a request to X12. At this time, we are not requiring payers to publicly report the reason for denial in these reporting metrics; that information is only provided to the requesting provider and the patient.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Another commenter recommended that state Medicaid agency reporting requirements be changed to begin 1 year following the implementation of the APIs (by March 31 of each year). Another commenter stated that the proposed metrics do not align with the data elements required to be reported for appeal for the Managed Care Annual Care Program Report (MCPAR) that states are required to report. The commenter stated that alignment is necessary to assess the impact of an MCO, PHIP, or PAHP's prior authorization determinations on beneficiary access to requested services.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree that any payer should begin their reporting period substantially after any other payer, as all payers already have data to support their prior authorization activities. Even if a state Medicaid agency were granted an exception or extension, their prior authorization processes are already in effect and they have data regarding their current prior authorization activities. The final action statement in this section of the final rule includes the compliance dates and reporting requirements for impacted payers, which remains March 31, 2026, for reporting data for the prior year. Concerning the MCPAR, alignment is neither necessary nor feasible. The MCPAR collects information specifically on appeals, and we are requiring information specifically on prior authorization. While it is true that a denied prior authorization could generate an appeal, that is not relevant to these two reporting vehicles. We may revise the data collected in the MCPAR in the future and will use the existing data from the MCPAR and this reporting to inform any such revisions.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS develop standard guidance or IGs for payers to have a set format and consistent calculation of the metrics. A commenter flagged that the lack of guidance on report formatting could lead to a wide variation across impacted payers. Another commenter stated that CMS should issue the guidance and allow adequate time for impacted payers and vendors to make the appropriate modification to their system before public reporting begins. A commenter sought clarification as to whether the public reporting of prior authorization metrics would only apply to prior authorization requests that are received on or after the compliance dates. Another commenter recommended that rule language specify the data required, ensure the data are placed prominently on the payers' websites, and indicate the cadence at which payers must refresh the publicly reported data. Many other commenters suggested various dissemination mechanisms for the prior authorization metrics. A commenter stated that they support an active distribution method for the prior authorization metrics, like a newsletter. Another commenter recommended that prior authorization metrics be available to be downloaded in Excel and PDF.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy. We will consider what additional support we can provide to impacted payers before the compliance date of the final rule regarding recommended content and format for use in their public reports. The requirement for data in the first report for prior authorization metrics to include information about prior authorization activity for the prior year will provide a baseline for impacted payers as well as the public. 
                        <PRTPAGE P="8893"/>
                        The reporting requirement applies to prior authorization requests that were received the year before the compliance date.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS report the required prior authorization information on the CMS website. A commenter stated that this will enable easy retrieval of data by physicians and patients, especially for plan comparison. Another commenter stated that CMS should also make sure it publishes this information on pages of its website that correlate to a particular payer. A commenter stated that CMS should report on the impact prior authorization has on the quality of care patients receive, potential delays in care, and associated cost savings due to the prior authorization process. The commenter suggested that reporting these data can help policymakers, researchers, providers, and patients make more informed decisions about the prior authorization process, ensuring that patient care remains central. Multiple commenters recommended that instead of payers publicly reporting metrics, there should be confidential reporting to CMS so it can track outliers and avoid misleading patients on data that are not comparable across plans. Another commenter recommended that CMS consider confidential payer reporting to CMS until the Prior Authorization API experiences significant uptake by providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We considered requiring that payers submit their reports to a central website for publication. However, as we explained in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76347), we did not select this alternative because we believe patients likely would view their health plan and payer as the resource for information about their plan. While CMS does provide comparative data for plans in certain programs (for example, the MA program) and may use such information in future public reports, we are not finalizing such an approach in this rule. Patients should be able to find information about their plan or payer from those websites to minimize burden and confusion. For Medicaid and CHIP, patients generally associate their coverage with their state or managed care plan, not CMS. While having the prior authorization data posted on each payer's website is the most appropriate place, we also encourage state Medicaid agencies to include the data on their websites (which are required by 42 CFR 438.10(c)(3)) to improve the value of information available to their patients. Similarly, MA patients look to their MA organization websites for information and resources about those plans and their performance. Payers must already include significant patient resource information on their websites, and CMS will conduct outreach to payers, patients, and providers to help provide guidance on best practices about the website locations for such public reporting of prior authorization information. In our oversight role, we may begin to look at data after the compliance date to evaluate compliance with these new reporting requirements. CMS may consider additional reporting requirements as well as publication of comparative information in the future.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated it would be helpful for additional context to explain metrics in the event of an outlier, such as explaining denial or approval rates for services-related data. Multiple commenters suggested including the total number of requests approved/denied, rather than only aggregate percentages. A commenter stated that they also would like to see specific data for common services to show a direct comparison across different payers and plans as certain prior authorization requests are more complex than others.
                    </P>
                    <P>Multiple commenters stated that service-specific reporting will aid in identifying services for which there is a high rate of approval and for which prior authorization requirements may no longer be necessary, or for identifying critical services or items being routinely denied. A commenter recommended CMS require payers to provide more detailed information by item or service including Healthcare Common Procedure Coding System (HCPCS) code, Current Procedural Terminology (CPT) code, and International Classification of Diseases, Tenth Revision (ICD-10) code. Other suggestions included requiring payers to report disaggregated data by diagnosis, race and ethnicity, gender, and age. A commenter warned that without item- and service-level reporting, it will be impossible for CMS and the public to understand some data and to hold impacted payers accountable for excessive denials and delays in responding to prior authorization requests. Other commenters recommended CMS require payers to report data with setting-specific data or by type of provider (for example, physician, short-term care, long-term care, rehabilitation, psychiatric, and skilled nursing services). A commenter stated that only with this setting level of specificity will patients and providers be able to assess which services are routinely denied, appealed, and overturned in favor of patients and providers. Another commenter warned that segmentation by the provider should encompass short-term acute care, long-term care, rehabilitation, psychiatric, and skilled nursing services to allow consumers, providers, and regulators to gain a better understanding of prior authorization processes and where there is a need for improvement. A commenter recommended that CMS should require metrics be broken down at the Health Care Provider Taxonomy code set Level II, Classification, which is a code set used in HIPAA standard transactions. Another commenter recommended that the metrics be reported by the payer based on service type, site of care, and whether the service is inpatient or outpatient. Another commenter wanted CMS to compare the metrics for MA organization plans to Medicare FFS and commercial health plans.</P>
                    <P>
                        <E T="03">Response:</E>
                         Service-specific and demographic reporting may be very useful to the impacted payers in evaluating their programs and expect that they use such data today and will continue to do so as they implement the policies of this final rule. While we agree that there could be many more reporting requirements, and at more granular levels, and data are an important tool for different evaluation purposes, reporting should serve its intended purposes and not become a burden to the users. Too much data can also become overwhelming. We anticipate patient and provider feedback following implementation and will review opportunities after that time.
                    </P>
                    <P>We agree that it would be appropriate to compare the metrics for all payers several years after the policies of this final rule have been implemented to determine its impact on the prior authorization barriers and burdens. However, commercial plans other than QHPs on the FFEs are not subject to the provisions of this rule, and CMS does not have access to performance data for those organizations. If states are collecting such data, they might be able to analyze the data at the state level.</P>
                    <HD SOURCE="HD3">b. Publication of Prior Authorization Metrics</HD>
                    <P>We requested comments on how the information might be displayed on payer websites in a useful and meaningful manner for patients and providers, including which data would be most useful. The summarized comments and our responses follow.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that the prior authorization metrics be presented in a readable and accessible format, particularly for individuals with 
                        <PRTPAGE P="8894"/>
                        disabilities, individuals with limited or low health and data literacy, and individuals with limited English proficiency. Other commenters recommended that CMS require plans to write publicly reported data at a sixth grade reading level, conduct consumer-focused testing on data readability, and provide translations in multiple languages. Multiple commenters recommended that CMS should require payers to provide access to prior authorization data in multiple languages (based on the most common languages in a community) and in a format that is comprehensible to the average consumer. A commenter recommended CMS should make the reported payer data patient-friendly and public to enable comparison of metrics.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenter suggestions that payer data be “patient-friendly,” easy to understand, and in an accessible format. We may consider how best to provide guidance to encourage impacted payers to develop their reports with these factors in mind, as the intent of these public reports is to ensure that individuals can use and interpret the information.
                    </P>
                    <HD SOURCE="HD3">c. Types of Prior Authorization Metrics</HD>
                    <P>Impacted payers are required to post a general set of prior authorization metrics on their public websites to support process improvement, as well as patient and provider insight into trends for different payers. While the data will not be submitted to CMS at this time, it will be available for public review and evaluation and may be informative as experience with the new policies evolves.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters wrote that CMS should include more data on use of the Prior Authorization API. A commenter suggested certain metrics be considered for adoption: the number of requests initiated using the Prior Authorization API, average response time for requests not requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization that had all of the required documentation available automatically, the percentage of Prior Authorization API requests requiring a prior authorization with all required documentation available processed automatically, the number of requests initiated using the Prior Authorization API requiring a prior authorization that were unable to automatically supply required documentation, and a list of all SMART on FHIR app/EHR combinations or equivalent technology used for Prior Authorization API requests at provider organizations. A commenter encouraged CMS to consider breaking reporting out by prior authorization transactions supported by a FHIR API transaction and those otherwise conducted.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The intended goal of publicly reporting these metrics is to help providers and patients gain insights into the payers' prior authorization practices and performance, and to assist payers in evaluating their prior authorization practices. While the performance and utilization of the Prior Authorization API is valuable information for assessing the adoption and use of the API itself, it may not adequately represent the full scope of a payer's prior authorization practices. As noted in a prior response, we may consider issuing guidance before the compliance date with more specifics on the recommended format and content; however, the lack of regulations or guidance on the format and content does not prevent payers from including additional information that could be of value to patients and providers.
                    </P>
                    <HD SOURCE="HD3">8. “Gold-Carding” Programs for Prior Authorization</HD>
                    <P>We solicited comments on the potential for gold-carding or prior authorization exemption programs and how they might reduce provider and payer burden and improve services to patients. We also solicited comments on the incorporation of such a measure into Star Ratings for these organizations. We received several comments on this topic and appreciate the input. Since no policies were proposed, we are not finalizing policies in this area at this time. We thank commenters for their feedback and will consider all comments for possible future rulemaking.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8895"/>
                        <GID>ER08FE24.008</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8896"/>
                        <GID>ER08FE24.009</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <PRTPAGE P="8897"/>
                    <HD SOURCE="HD3">9. Final Action</HD>
                    <P>After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications:</P>
                    <P>• Impacted payers must implement and maintain a Prior Authorization API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.</P>
                    <P>• MA organizations must report prior authorization metrics at the contract level rather than at the proposed organization level.</P>
                    <P>See further discussion for exact details of the final requirements for impacted payers.</P>
                    <P>We are finalizing that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Prior Authorization API that is compliant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG at 45 CFR 170.215(c)(1).</P>
                    <P>We are finalizing that, by the compliance dates, impacted payers must implement a Prior Authorization API that:</P>
                    <P>• Is populated with the payer's list of covered items and services (excluding drugs) that require prior authorization;</P>
                    <P>• Can identify all documentation required for approval of any items or services that require prior authorization;</P>
                    <P>• Supports a HIPAA-compliant prior authorization request and response; and</P>
                    <P>• Communicates whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information.</P>
                    <P>We are finalizing that, beginning 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), impacted payers' must provide a specific reason for a denial within their decision timeframe regardless of the method that was used to send the prior authorization request or decision.</P>
                    <P>We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, state Medicaid and CHIP FFS programs, and Medicaid managed care plans and CHIP managed care entities must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests, unless a shorter minimum timeframe is established under applicable state law.</P>
                    <P>We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, and state Medicaid and CHIP FFS programs, must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law. That requirement already exists for Medicaid managed care plans and CHIP managed care entities, but for consistency with Medicaid FFS, we are finalizing that those payers must also send notices to patients and comply with a shorter timeframe, if established by state.</P>
                    <P>In response to public comments, CMS will work with state Medicaid and CHIP FFS programs that may be unable to meet the new prior authorization decision timeframes compliance date in 2026. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframes requirements will be temporary and limited to the unique circumstances of the program.</P>
                    <P>We are finalizing that, as of the effective date of this final rule, existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions.</P>
                    <P>We are finalizing that, beginning in 2026, impacted payers must annually report certain aggregated prior authorization metrics. Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans and CHIP managed care entities at the plan level, and QHP issuers on the FFEs at the issuer level must post the required metrics on their websites. Impacted payers must publicly report the previous calendar year's metrics by March 31 following any year that they offered that type of plan.</P>
                    <P>These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table E4.</P>
                    <HD SOURCE="HD3">10. Statutory Authorities To Require Improvements in Prior Authorization Processes, Decision and Notification Timeframe Policies</HD>
                    <P>We did not receive any public comments on the statutory authorities for the Prior Authorization API and prior authorization process policies discussed in this section.</P>
                    <HD SOURCE="HD3">a. Medicare Advantage</HD>
                    <P>
                        Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with, and carry out, Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization or other review requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service, and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician involved, as appropriate) of an expedited determination (and reconsideration) under time limitations established by the Secretary, but not later than 72 hours after the time of receipt of the request. The prior authorization requirements in this final rule ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized 
                        <PRTPAGE P="8898"/>
                        fashion and in compliance with standards that carry out and serve the purposes of the MA program.
                    </P>
                    <P>Under the authorities referenced previously, we are finalizing certain requirements for MA organizations. These requirements are to ensure that MA organizations provide enrollees with appropriate access to care and information by using certain standards, technologies, and business processes. The requirements include implementing certain APIs that provide information about the coverage and documentation requirements for prior authorization, responding to prior authorization requests with the status of that request, and meeting certain timeframes for making decisions on prior authorization requests.</P>
                    <P>We are requiring that MA organizations implement the Prior Authorization API using certain implementation specifications as discussed in section II.G. of this final rule. These implementation specifications are expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today concerning providers' access to information about the prior authorization rules and documentation requirements. The Prior Authorization API will communicate the coverage and documentation requirements for prior authorization, indicating if authorization is required for a specific item or service and what documentation is required to support an authorization request. Use of the Prior Authorization API is consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of the Act by disclosing to providers the same information that generally must be provided to enrollees about which covered benefits are subject to prior authorization and serves the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services.</P>
                    <P>Additionally, the Prior Authorization API is a mechanism for receiving and responding to requests for coverage determinations before the services are rendered or items furnished; therefore, the requirement to adopt and use the Prior Authorization API is an additional standard for implementing and complying with section 1852(g) of the Act regarding an MA organization's obligation to make coverage determinations. The Prior Authorization API will enable the provider to submit a HIPAA-compliant prior authorization request through their existing workflow and receive a timely response to that request. In concert with these APIs, we are requiring the payer to provide the status of the request, such as whether it was approved or denied, along with a specific denial reason, so that the provider knows what steps to take next—whether to request a different service for the patient, to submit additional information, or to appeal the decision. These final requirements will improve patient care and reduce redundancies in administrative processes between providers and payers because they give providers clearer instructions, both for submitting the original request and, if necessary, providing additional information. The required API has the potential to improve the efficiency of the prior authorization process because it enables providers to submit accurate information with the request, which could reduce the number of appeals or denials, and possibly eliminate requests for additional documentation.</P>
                    <P>We expect the prior authorization policies in this final rule to improve timely access to care for beneficiaries by mitigating delays that sometimes occur when a provider is trying to determine coverage requirements or does not know what documents to submit to obtain approval for a service. Improvements in the timeliness of payer operations and provider services will contribute to program efficiency, and effective operations and will be in the best interest of the enrollees. The requirement for MA organizations to make certain changes to the timeframes in which they provide notice for prior authorization has the potential to improve patient access to care in program operations as discussed in section II.D.5. of this final rule. This could prevent some patients from abandoning care while waiting for authorization, and it could improve efficiencies by avoiding repeat phone calls from providers who must check on the status of authorization over several days, or sometimes weeks. We finalized requirements to improve some timeframes for expedited and standard decisions under the premise that these changes are overdue, feasible, and would benefit patients and providers. Furthermore, by establishing more certainty in the process for providers, there may be a reduction in unnecessary repeat requests for services. More responsive timeframes will also enhance enrollee access to timely and appropriate care. A shorter timeframe for both standard and expedited decisions may reduce administrative time and expense for providers and payers, as they would spend fewer resources on follow-up inquiries. As such, these requirements are consistent with our authorities to adopt standards to carry out and implement the requirements in section 1852 of the Act for MA organizations to have a procedure for making timely determinations and to make benefits available and accessible with reasonable promptness.</P>
                    <P>Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting requirements by MA organizations where necessary and appropriate. The requirement for MA plans to publicly report prior authorization metrics will enable CMS to assess the implementation of the policies and attempt to determine the impact of these new requirements on payers and providers. A review of these metrics may help CMS and the plans understand the impact of the requirements, including the impact of using the APIs and improved decision timeframes. The data may also help plans evaluate operations, implement new policies and the API, and determine what changes may be appropriate.</P>
                    <HD SOURCE="HD3">b. Medicaid</HD>
                    <P>For Medicaid, most of the requirements finalized in this section are authorized by sections 1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan, section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals, and section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with the simplicity of administration and the best interests of the recipients. Some requirements finalized in this section are also authorized by additional sections of the Act as discussed in this section of the final rule.</P>
                    <P>
                        Additionally, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the program or plan. The implementing regulations at 42 CFR part 431, subpart F, for this section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with the administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain 
                        <PRTPAGE P="8899"/>
                        requirements to restrict uses and disclosures of Medicaid beneficiary data. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b).
                    </P>
                    <P>Our finalized policy that the data described in this section be shared via the Prior Authorization API is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. This data sharing policy for the Prior Authorization API is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). The services include those for which the state requires that a provider submit a prior authorization request, and thus needs to communicate about that prior authorization with other providers enrolled with or authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral part of the Medicaid program and facilitates access to care as well as provider payment processes.</P>
                    <P>We remind states that to meet the requirements of the regulations at 42 CFR part 431, subpart F, states must have consistent criteria for the release and use of information (which should comply with the proposed Prior Authorization API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). Similar to the Provider Access API discussed previously, the permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to the Prior Authorization API, because any request for beneficiary information would be from an enrolled Medicaid or CHIP provider and thus would not be from an outside source. While the beneficiary's permission is not required under 42 CFR 431.306(d) for the Prior Authorization API, state or other laws may require such permission. When requesting approval to provide certain services from the state using the state's Prior Authorization API as described in section II.D.2.a. of this final rule, the provider will be able to determine if prior authorization is required and what supporting documentation is necessary to obtain approval for that care.</P>
                    <HD SOURCE="HD3">i. Prior Authorization API</HD>
                    <P>The requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the Prior Authorization API is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process today. As discussed in section II.D.2.a. of this final rule, the Prior Authorization API will allow a provider to determine whether a prior authorization is required and the documentation requirements for that prior authorization request. The Prior Authorization API will:</P>
                    <P>• Enable providers to submit a complete prior authorization request faster and easier;</P>
                    <P>• Support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and</P>
                    <P>• Permit improved scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including by reducing the number of denials and appeals, or even by eliminating requests for additional documentation, as noted elsewhere in this final rule.</P>
                    <HD SOURCE="HD3">ii. Requirement for Payers To Provide Specific Reason for Denial of Prior Authorizations</HD>
                    <P>Based on the provisions of this final rule, states and Medicaid managed care plans must provide specific information to providers about the status of prior authorization requests to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.3. of this final rule, when providers receive a response to a prior authorization request, the payer will typically indicate whether the request is approved, or denied, or if additional information is needed. If prior authorization has been denied, the payer must give the provider the specific reason for the denial; that information may be used by the provider to decide next steps, such as re-submitting the request with updated information, identifying alternative treatments for the patient, or appealing the decision. These requirements will improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests; help providers determine the next steps for timely patient care; and reduce payer, provider, and patient burden by eliminating the need for repeated inquiries.</P>
                    <HD SOURCE="HD3">iii. Requirements for Prior Authorization Decision Timeframes, Notifications Related to Prior Authorization Decision Timeframes, and Amendments to Existing Medicaid Fair Hearings and Appeals Regulations</HD>
                    <P>As discussed in section II.D.5. of this final rule, delayed prior authorization decisions may directly affect patient care by delaying access to treatment, services, and supplies, as well as transfers between hospitals and post-acute care facilities. The required timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs will help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. These requirements should make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes will contribute to more efficient use of Medicaid program resources.</P>
                    <P>The requirement to shorten the maximum amount of time for a Medicaid managed care plan to make a prior authorization decision from 14 calendar days to 7 calendar days will improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals.</P>
                    <P>
                        Our amendment to explicitly state in the regulation text that current notice and fair hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. This is also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically, 
                        <E T="03">Goldberg</E>
                         v. 
                        <E T="03">Kelly,</E>
                         397 U.S. 254 (1970). States must establish timely notice and fair hearing processes meeting due process standards under 
                        <E T="03">Goldberg</E>
                         v. 
                        <E T="03">Kelly,</E>
                         as incorporated into existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E, see 42 CFR 431.205(d).
                    </P>
                    <P>
                        Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include reasonable standards for determining the extent of medical assistance under the plan that are 
                        <PRTPAGE P="8900"/>
                        consistent with the objectives of Title XIX of the Act. As set forth at 42 CFR 440.230, the standards that states establish under section 1902(a)(17) of the Act could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, as long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could include prior authorization requirements. The requirements to establish timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act because they would be expected to help ensure that states make prior authorization decisions in a manner that is consistent with the requirements in section 1902(a)(4), (a)(8), and (a)(19) of the Act, thus helping to ensure that states' standards for determining the extent of medical assistance under the plan are consistent with the objectives of Title XIX.
                    </P>
                    <P>Section 1932(b)(4) of the Act provides that each Medicaid MCO must establish an internal grievance procedure whereby a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has implemented requirements for those procedures at 42 CFR 438.210, which applies the same appeal and grievance requirements for PIHPs and PAHPs as for Medicaid MCOs. We rely on our authority in section 1902(a)(4) of the Act to adopt standards for PIHPs and PAHPs that mirror requirements for MCOs. This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507). We rely on the same authority here to revise the procedures under which Medicaid managed care plans may make prior authorization decisions about coverage and provide those decisions to providers and enrollees. Reducing plan response time for prior authorization decisions may enable beneficiaries to file appeals if necessary and receive a resolution to those appeals sooner. The earlier an appeal is filed, and the disposition known, the sooner the provider and beneficiary can determine whether to request a state fair hearing or to identify treatment alternatives, if necessary. The prior authorization requirements in this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a provision for an annual external quality review of quality outcomes and access to and timeliness of covered services. If the shorter prior authorization response requirements successfully improve workflow and processes that facilitate timely access to services, improvements to the care experience for patients, and better health outcomes, the results should be visible in external reviews. This requirement reflects the importance and potential advantages of timely access for beneficiaries to covered services through more efficient processing of prior authorization requests as proposed in this rule.</P>
                    <HD SOURCE="HD3">iv. Public Reporting of Prior Authorization Metrics</HD>
                    <P>We are also requiring Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them on the payer's website. As discussed in section II.D.7. of this final rule, publicly reporting these metrics may support more timely access to services by identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action, and for managed care programs, helping beneficiaries select Medicaid managed care plans that best meet their needs and helping some Medicaid providers make informed decisions on which Medicaid managed care plan networks to join.</P>
                    <P>Section 1902(a)(4) of the Act authorizes this requirement because enabling more timely access to services by identifying prior authorization deficiencies and facilitating the implementation of corrective action to improve the prior authorization process will support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics will hold them accountable and enable them to monitor their performance and identify process improvement opportunities, which may be an integral part of implementing a quality assessment and improvement strategy more easily. This is consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act.</P>
                    <P>Section 1902(a)(8) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action as well as helping beneficiaries select a Medicaid managed care plan that best meets their needs may improve the promptness with which services are provided to beneficiaries. Section 1902(a)(19) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action will help ensure that care and services are provided in a manner consistent with the simplicity of administration. Additionally, implementation of corrective action to improve prior authorization processes, helping beneficiaries select a managed care plan that best meets their needs, and helping providers make informed decisions on which Medicaid managed care plan networks to join is in the best interest of beneficiaries.</P>
                    <HD SOURCE="HD3">c. CHIP</HD>
                    <P>For CHIP, we finalized these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively and efficiently that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services.</P>
                    <P>As discussed previously, we are requiring the implementation of the Prior Authorization API in section II.D.2.a. of this final rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist currently. Today, a payer's rules about when prior authorization is required and what documentation requirements must be fulfilled to submit the request are not necessarily easily accessible for providers. The Prior Authorization API will enable a provider to determine if a prior authorization is required electronically, in real-time and what the documentation requirements are regarding such requests. While we expect providers to be the primary beneficiaries of this API, making this information available in a standardized way and permitting access through an API will also serve the requirements in section 2101(a) of the Act that CHIP ensures access to coverage and coordinated care.</P>
                    <P>
                        The Prior Authorization API is a mechanism for receiving and responding to requests for coverage 
                        <PRTPAGE P="8901"/>
                        determinations before the services are furnished; this API will streamline the initial authorization process for the payer by sharing this information in an easily accessible way. The API will also allow the provider to know what to do if prior authorization is required for a certain service, which will improve the provider's ability to treat the patient timely. The Prior Authorization API enables the payer to send a real-time response back to a provider, based on the request for authorization. This, too, will improve the efficiency of providing services to the patient because the request and response are automated and in real-time. We expect payers' use of this API to ensure that a provider can submit a request for prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The Prior Authorization API will: (1) enable providers to submit a prior authorization request faster and easier; (2) support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and (3) permit faster scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even eliminating requests for additional documentation, as noted elsewhere.
                    </P>
                    <P>The safeguards for beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP payers' and providers' data exchange through the Prior Authorization API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information about individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.</P>
                    <P>The requirement in section II.D.5. of this final rule that CHIP FFS and CHIP managed care entities meet certain timeframes to provide decisions for prior authorizations for expedited and standard decisions is an improvement from the current state, where there is uncertainty about expectations for when a prior authorization might be approved. This requirement is intended to establish more certainty in the prior authorization process for providers and improve access to appropriate care for all patients, particularly those with chronic conditions or complicated health risks. Health parity may be increased as barriers due to process and timeframes will be removed. Similarly, improved process improvements may reduce administrative costs for providers and payers as redundancies will be removed from the system. We expect the requirement to improve timeliness in responding to providers and patients to support process improvements for the state and managed care programs and is consistent with our authorities under section 2101(a) of the Act in that it improves the efficiency of the CHIP programs.</P>
                    <P>The policy to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics will also support the states' oversight, evaluation, and administration responsibilities. CMS may occasionally view some of the CHIP's FFS and managed care websites to check for compliance, see how data are being reported, and determine if any trends in prior authorization changes could be indicative of the benefits of the prior authorization policies as discussed in section II.D.7. of this final rule. The data may indicate the use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals.</P>
                    <HD SOURCE="HD3">d. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>For QHP issuers on the FFEs, we finalized the requirements in this section under the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.</P>
                    <P>The policies finalized here may improve the efficiency of the issuers that are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients by increasing the efficiency in the prior authorization submission and review process. In section II.D.2.a. of this final rule, we are requiring that QHP issuers on the FFEs implement an API to support the prior authorization process. The Prior Authorization API will allow QHP issuers on the FFEs to communicate requirements for prior authorization more efficiently and enable providers to similarly operate more efficiently to determine when a prior authorization is needed and locate the documentation requirements. The Prior Authorization API may enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving the delivery of services to patients. Qualified individuals enrolled in QHPs on the FFEs may receive covered services more quickly using the API. Similar to the other APIs, we believe that certifying only health plans that implement the Prior Authorization API and adhere to the other requirements described in this section of the preamble is in the interests of qualified individuals in the state or states in which a QHP issuer on the FFEs operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act. We encourage SBEs to consider whether a similar requirement should apply to QHP issuers participating in their Exchanges.</P>
                    <P>We are also requiring that QHP issuers on the FFEs provide a specific reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This may enable efficient and successful resubmission of the previously denied prior authorization request, which may more promptly facilitate the needed patient care.</P>
                    <P>Finally, the requirement for QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.7. of this final rule will hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data may help QHP issuers on the FFEs evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of the coverage and documentation information included in the APIs.</P>
                    <HD SOURCE="HD2">E. Extensions, Exemptions, and Exceptions and Federal Matching Funds for Medicaid and CHIP</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>
                        The CMS Interoperability and Prior Authorization proposed rule discussed extensions, exemptions, and exceptions for state Medicaid and CHIP FFS Programs and QHP issuers on the FFEs, Federal funding available to states, and applicability to state Medicaid expansion programs for CHIP populations. As stated in the Provider Access, Payer-to-Payer, and Prior Authorization API sections of this final rule we are consolidated in one section the requirements for applying for an 
                        <PRTPAGE P="8902"/>
                        extension, exemption, or exception. Here we discuss those proposals, provide responses to the comments received regarding the proposals, and include the final policies.
                    </P>
                    <HD SOURCE="HD3">2. Extensions, Exemptions, and Exceptions</HD>
                    <HD SOURCE="HD3">a. Extensions and Exemptions for State Medicaid and CHIP Fee-for Service</HD>
                    <P>In the proposed rule we explained that state Medicaid and CHIP FFS agencies face certain unique financing and operational circumstances that would not apply to other impacted payers. For example, some states would need legislative approval to initiate a public procurement process to secure contractors, particularly those with the necessary skills to support a state's implementation of the policies that require API development or enhancement. The timeline for an openly competed procurement process, together with the time needed to onboard contractors to develop the APIs can be lengthy for states (87 FR 76302). We described the issues impacting the state Medicaid and CHIP FFS programs in the proposed rule for the Provider Access (87 FR 76261), Payer-to-Payer (87 FR 76279), and Prior Authorization (87 FR 76302) APIs. However, we also stated that if our proposals regarding these APIs were finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement them as soon as possible, because of the anticipated benefits for the impacted payers, patients, and providers. Therefore, to address implementation concerns for state Medicaid and CHIP FFS programs, we proposed a process through which states could seek an extension to, and, in specific circumstances, an exemption from, the requirements to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs.</P>
                    <P>We also proposed that states could request a one-time, 1-year extension through their annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures. We also proposed to permit state Medicaid FFS programs to request an exemption from any or all of these three API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid MCOs as defined at 42 CFR 438.2. Similarly, we proposed that separate state CHIP FFS programs could request an exemption from the API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP MCOs as defined at 42 CFR 457.10. We proposed that states could apply for an exemption by submitting a written request for the exemption as part of the annual APD for MMIS operations expenditures. CMS approves project plans and enhanced FFP for Medicaid Enterprise Systems (MES) using the APD process. CHIP waiver requests and expenditures for systems are managed at CMS in the operations division responsible for management of APDs. Guidance on the application process is available through each state's Regional Office contact.</P>
                    <P>As discussed in section II.C.4.b. of this final rule, we proposed and are finalizing, that for the payer to payer data exchange, state Medicaid and CHIP programs, rather than their managed care plans or managed care entities, will be responsible for obtaining beneficiaries' permission, providing educational resources at the time of requesting permission, and identifying patients' previous/concurrent payers, including for beneficiaries covered under managed care (87 FR 76280). Therefore, we also proposed that an exemption would not apply to those requirements, but only the API requirements, because it would prevent Medicaid managed care plans and CHIP managed care entities from meeting their obligations.</P>
                    <P>For Medicaid managed care plans and CHIP managed care entities, we did not propose an extension process because we believe that these managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the requirements at 42 CFR 438.272(d)(5) and 42 CFR part 457. Many of these plans might benefit from efficiencies based on all of the plan types that they offer. For example, many of these managed care plans with Medicaid and CHIP beneficiaries are part of a larger organization serving MA and Marketplace populations. These larger organizations often provide the technical and operational capacity that would enable implementation of the APIs across all lines of business. We believe this would be a practical and efficient use of resources to service all enrollees. Additionally, because the majority of Medicaid beneficiaries receive all or some of their benefits in a managed care delivery system, these plans should be held to the implementation times finalized in this rule to support the intended policy goals. Please see 87 FR 76263 for the supporting narrative in the proposed rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for the proposed Medicaid and CHIP FFS extension policy and urged CMS to finalize this flexibility regarding compliance with the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Multiple commenters highlighted extenuating circumstances that state Medicaid and CHIP agencies may face, especially related to the conclusion of the COVID-19 public health emergency (PHE), and the resulting impact on IT and personnel resources.
                    </P>
                    <P>Multiple commenters submitted comments about which APIs should be included in the extensions, exemptions, and exceptions proposals and some recommended that CMS extend these flexibilities to all APIs included in the rule. A commenter recommended that CMS provide clarity regarding the exemption and extension provisions for the Patient Access API requirements.</P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that states will be conducting long-term efforts to return to normal Medicaid and CHIP operations after the end of the COVID-19 PHE and the continuous enrollment condition under section 6008(b)(3) of the FFCRA. These efforts will continue through 2024, and many of these states have ongoing system development initiatives that require integration with MES and modules. Some states must work within their state legislative budget request cycle, as well as the Federal request cycle for requesting and obtaining funds for updates to their systems or new contracts.
                    </P>
                    <P>
                        We reiterate that this final rule requires impacted payers to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs. Impacted payers should have already implemented or begun implementation of the Patient Access and Provider Directory APIs as required in the CMS Interoperability and Patient Access final rule, except for those organizations that have approved exceptions, as applicable.
                        <E T="51">148 149</E>
                        <FTREF/>
                         We did not propose a new Patient Access API, but rather additional data requirements for that API, and reporting requirements for use metrics. We did not propose any new 
                        <PRTPAGE P="8903"/>
                        extensions, exemptions, or exceptions for the Patient Access API in the proposed rule and are not adding policies of that nature in the final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             In the CMS Interoperability and Patient Access final rule, we finalized that Patient Access API provisions would be effective beginning January 1, 2021. We announced a 6-month enforcement discretion exercised as a result of the PHE until July 1, 2021.
                        </P>
                        <P>
                            <SU>149</SU>
                             For example, 45 CFR 156.221(h) permits the FFE to grant an exception on an annual basis to the requirements in paragraphs (a) through (g) of that section for an FFE QHP if the Exchange determines that making their health plan(s) available through the Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and the QHP issuer submits a narrative justification describing the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding the proposed state Medicaid and CHIP FFS extension policies, specifically citing the importance of the impact of these policies on Medicaid enrollees, and on the need for provider adoption to truly achieve the burden reduction goals of the proposed rule for patients, payers, hospitals, and providers. A commenter recommended that CMS not allow certain payers to have extensions because this could affect provider adoption of the necessary technology. Another commenter expressed appreciation of CMS for the proposal to allow extensions but stated that they believe provider adoption is going to be the most important factor in achieving burden reduction. The commenter emphasized the importance of having a certain percentage of their prior authorizations be electronic so that there is a return on investment from the changes necessary (for example, workflow changes, training, IT changes). The commenter stated that if payers are not held to the requirements in the rule, it could be perceived as a disincentive to providers to invest in the necessary technology.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for confirmation that payers must be held accountable for implementation of the APIs, and that provider adoption of certain APIs is going to be an important factor in achieving burden reduction—particularly the Prior Authorization API. Participation by both payers and providers in some of the API provisions of this final rule will be important to ensure widespread adoption of the APIs. Because we also believe that provider participation is important for the Prior Authorization API, we are finalizing a modification to our proposal to adopt new Electronic Prior Authorization measures to incentivize providers (specifically, MIPS eligible clinicians, eligible hospitals, and CAHs) to use the Prior Authorization API under MIPS and the Medicare Promoting Interoperability Program as discussed in section II.F. of this rule. We also reiterate that while these extensions and exemptions apply to the new API provisions of this final rule, other policies must still meet the compliance dates established in this final rule. These include the prior authorization information to be included in the Patient Access API; information required under the finalized prior authorization process, such as providing a specific reason for denial, and revised timeframes for issuing prior authorization decisions. We encourage states to communicate their implementation plans about the policies in this final rule (including those to which an extension or exemption may apply) to network and enrolled providers. Such communication may help providers prepare for changes in procedures or notify their vendors to make appropriate system changes on a similar schedule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter said that the exemption for the APIs was a concern because it creates an unfair, two-tiered system that may leave people with disabilities behind; these people already face high barriers to care due to administrative burdens and uncertainties caused by prior authorization. The commenter wrote that the proposed exemption process will leave some FFS Medicaid populations—groups that include a disproportionate share of people with disabilities—without comparable access to any benefits derived from streamlining the prior authorization process with the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted the potential challenges of developing and maintaining the necessary data infrastructure for a relatively small FFS population, but wrote that in many states, people receiving Home and Community-Based Services (HCBS) through waivers that are carved out of managed care, may be individuals who would fall under the proposed API exemption and would fail to benefit from the streamlined prior authorization process in this regulation. Another commenter requested clarification on whether and how CMS considered health equity when proposing exemptions for some state Medicaid and CHIP programs. Other commenters expressed disagreement with the proposed exemptions and stated that these exemption proposals should be withdrawn, to make the APIs available to every Medicaid beneficiary. A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that it is important to consider access and equity issues, and the risk of a two-tiered system that may impose barriers to care. CMS will only grant a state an exemption from the Provider Access, Payer-to-Payer, and Prior Authorization APIs if the state establishes an alternative plan to enable the electronic exchange and accessibility of the required information that would otherwise be shared through the API. For example, CMS will only grant a state an exemption from the Provider Access API requirement if the state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same required data content about their patients through other means while the approved exemption is in effect. Similarly, states would be expected to use efficient means for electronic prior authorization that would reduce burden for providers and improve access to information about the requirements for when prior authorization is required for items and services or what documentation is required in advance. In light of requirements for the accessibility of this information, states implementing an alternative plan will be required to provide this information to all patients and providers in plain language and to offer auxiliary aids and services to ensure effective communications with individuals with disabilities.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS include managed care plans in the proposed flexibilities (for extensions and exemptions) and some commenters said that each state should be able to decide whether to allow an extension to managed care plans. A commenter noted that managed care plans have greater resources than state Medicaid and CHIP FFS programs and would be able to meet the rule requirements on time. On the other hand, a commenter recommended that state Medicaid agencies offer managed care plans a 1-year extension.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge commenters who recommended that CMS provide the opportunity for an extension or exemption to Medicaid managed care plans and CHIP managed care entities to align with our approach throughout the rule to apply most policies to both state Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care entities. However, we reiterate that the purpose of the extension policy for state Medicaid and CHIP FFS programs is to provide states that are making a good faith effort with additional time to work through lengthy and complex state procurement processes, to secure the necessary funding, personnel, and technical resources to successfully implement the requirements. The purpose of the exemption policy for state Medicaid and CHIP FFS programs is to accommodate the different enrollment models that are now in effect for each state and provide consideration 
                        <PRTPAGE P="8904"/>
                        for states with relatively small FFS populations. In response to these and many other comments requesting additional time for payers to implement the Provider Access, Payer-to-Payer, and Prior Authorization APIs, we are extending the compliance dates for the policies in this final rule that require API development or enhancement to 2027. This allows all impacted payers an additional year to meet these requirements, compared to our initial proposal to implement the requirements in 2026. We are finalizing the state Medicaid and CHIP FFS extension and exemption policies as proposed without extending this option to other payers in the Medicaid program, such as Medicaid managed care plans. We do not agree with commenters who suggested that each state be able to decide separately to allow an extension to managed care plans because the purpose of this final rule is to encourage adoption of these policies as soon as is practicable. As we have noted, Medicaid managed care plans are often owned and operated by larger private organizations, also subject to this final rule, and likely have the resources and capabilities to implement these policies and can efficiently leverage the work they do to build APIs across their Medicaid, MA, and Marketplace lines of business. We do not want to encourage a system where fewer Medicaid beneficiaries have access to the benefits of the policies in this final rule versus those with other types of coverage.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters provided recommendations regarding additional payers and plan types that should be eligible to benefit from the extensions, exemptions, and exceptions proposals. Multiple commenters recommended that CMS extend these flexibilities to all impacted payers. For example, a commenter recommended that HHS consider permitting state Medicaid and CHIP agencies that have a direct relationship with patients and providers to be eligible for extensions, exemptions, or exceptions. Another commenter recommended that CMS create an exception process for state Medicaid agencies in states or territories with HIEs that would give participating providers the same data as the Provider Access API. Some Medicaid agencies report concerns about duplication with these HIEs, as this would be an inefficient use of resources, could confuse providers, and may inhibit efforts to expand HIEs. A commenter wrote that CMS should create an exception process for Medicaid agencies in states or territories with robust HIEs that provide access to the same data. Another commenter recommended that CMS consider exception and extension criteria for plans where the proposed timelines and requirements would jeopardize their ability to operate.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank all commenters for their input regarding extensions, exemptions, and exceptions for all payers. We are finalizing the extensions and exemptions policies as proposed for state Medicaid and CHIP FFS programs without extending them to additional payers because state Medicaid and CHIP FFS programs face certain unique challenges. As noted previously, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have many discrete health care plans, and therefore cannot balance implementation costs across plans with low enrollment and those with higher enrollment. As stated at the beginning of this section, many states have complex procurement and staffing/recruitment challenges which do not apply to non-governmental organizations. We acknowledge HIEs could be helpful partners for payers when implementing these APIs. Nothing in this rule would prohibit a state from partnering with an HIE to meet its requirements. Further discussion regarding HIEs can be found in sections II.B.3.b.iii. and II.C.3.a. of this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that CMS include extensions and/or exemptions in the proposal for MA organizations, Special Needs Plans (SNPs), D-SNPs, or Institutional Special Needs Plans (I-SNPs).
                        <SU>150</SU>
                        <FTREF/>
                         A commenter wrote that CMS should also permit extensions and exemptions for MA organizations offering integrated D-SNPs, especially if CMS does not finalize a phased-in approach to implementation. The commenter wrote that some of these payers are facing the challenge of unwinding current flexibilities implemented due to the PHE and are also facing significant requirements in coming years as finalized in the CY 2024 MA and Part D final rule (88 FR 22120). Another commenter asked that CMS consider whether there may be appropriate circumstances where it would be permissible for very small MA organizations, such as SNPs or I-SNPs to seek a one-time extension to the compliance dates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             We note for readers that MA organizations offer MA plans, which include SNPs (including the specific types of SNPs mentioned by commenters—D-SNPs and I-SNPs), so we address these comments together.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose extensions or exemptions for MA organizations or Medicaid managed care plans, including plans that integrate managed care Medicare and Medicaid benefits (for example, D-SNPs or applicable integrated plans). We have provided explanations for excluding Medicaid managed care plans in previous responses. We believe that most MA organizations are supported by entities with an operational and technical infrastructure that can support the API requirements because these organizations can leverage existing staff and vendor resources from implementation of the Patient Access and Provider Directory APIs. Further, MA organizations should have the operational infrastructure to analyze and implement the requirements for the new APIs based on that expertise. Finally, because we did not propose extensions or exemptions for MA organizations in the proposed rule, we cannot finalize such a policy for these entities in this rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters recommended that CMS grant exemptions for states that are already implementing electronic prior authorization solutions or state-level policies that conflict with the proposed Prior Authorization API requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The option for states to apply for an exemption exists to alleviate burden for states with small FFS populations and that have established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect. We will not grant exemptions for situations where state law conflicts with the final rule. The final rule pre-empts any conflicting state law.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS consider allowing states to obtain two 1-year extensions. A commenter stated that an additional, 1-year extension would allow states to better meet the proposed requirements. Another commenter noted that states face certain challenges that may be out of their control and prolong implementation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         After consideration of comments received and for the reasons outlined in our response to these comments, we are extending the compliance dates for all of the polices that require API development or enhancement finalized in this rule to begin January 1, 2027, which will allow for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule. This applies to the compliance dates for the Provider Access, Payer-to-Payer, and Prior Authorization APIs. State Medicaid and CHIP FFS programs will 
                        <PRTPAGE P="8905"/>
                        be eligible to apply for up to a 1-year extension as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposal regarding exemptions for state Medicaid and CHIP FFS programs and recommended that CMS finalize these proposed flexibilities regarding implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter indicated that in reviewing exemption requests and the compliance dates in the proposed rule, as well as other information system projects that are in development, their plans to implement a comprehensive systems integration platform that would integrate the MES would necessitate the option for an exemption. This commenter indicated that the project was particularly urgent due to the end of system support for another legacy system. Another commenter recommended that CMS use a flexible interpretation for the exemption process and noted that it would not be reasonable to require a state to build out APIs for a Federal Emergency Services Program (FESP), explaining that some agencies report having a high number of FFS enrollees in an FESP, such that less than 90 percent of their members are technically enrolled in managed care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for the proposed exemption process, as well as for the simultaneous encouragement for payers to secure the necessary resources to implement the technology for the prior authorization and other APIs being finalized in this rule. We also confirm that the policy in this final rule does not apply to FESPs, and that other payers are not being considered eligible for exemptions, extensions, or exceptions at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption. A commenter stated that larger states qualifying for an exemption will have a total number of FFS beneficiaries that is greater than the total Medicaid population of smaller states that would not qualify for the exemption.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         CMS needs to balance the benefits to small populations of beneficiaries with the burden of new operations and costs being placed on states. CMS will not approve exemptions unless a state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information, including prior authorization information, through other means while the exemption is in effect, or that states are providing efficient electronic access to other payers. Additionally, state agencies with an approved exemption will be required to meet the policies that do not require API development or enhancement for their FFS populations (that is, the reduced prior authorization decision timeframes, providing a specific reason for a denial, and reporting prior authorization metrics). These policies, to the extent they will mitigate barriers to care or support improvements in the transparency of information between the states and providers, are part of the overall scope for this final rule to address challenges with prior authorization. Concerning the methodology states use to apply and be approved for an exemption, we believe we have provided a threshold where a state could appropriately claim an exemption without taking actions that would inappropriately influence the enrollment process or individual enrollee's enrollment decisions. States' use of enrollment brokers for choice counseling and enrollment processing also protects enrollees from undue pressure during the enrollment process. We remind states of the enrollee protections specified at 42 CFR 438.54 and 457.1210 for Medicaid and CHIP managed care enrollment respectively, as well as disenrollment rights specified at 42 CFR 438.56(c) and 457.1212, respectively.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter urged CMS to use a flexible interpretation for the exemption process for the API requirements for Medicaid agencies with at least 90 percent of their members enrolled in managed care, noting that some states have a high number of FFS beneficiaries in an FESP that are only covered for emergency care. The commenter stated that it would not be reasonable to require a state to build out APIs for beneficiaries and programs that cover such a narrow scope of services.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter highlighting that some states may have larger populations in FFS where beneficiaries are not receiving comprehensive benefits and thus may experience only limited value from the APIs. Our intent with establishing this condition for exemption approval is that no FFS population will experience diminished health care delivery or information exchange capabilities as a result of an approved exemption. The exemption intends to alleviate the cost burden of implementing the API provisions on state Medicaid and/or CHIP agencies with small FFS populations, regardless of the scope of their benefit package. We remind states that CMS will grant an exemption if the state establishes to CMS's satisfaction that the state meets the criteria for the exemption and has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect, including patient information and prior authorization information.
                    </P>
                    <HD SOURCE="HD3">b. Exception for Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>For QHP issuers on the FFEs, we proposed an exception process to the Provider Access, Payer-to-Payer, and Prior Authorization APIs for issuers applying for QHP certification that cannot satisfy the proposed requirements. To apply for an exception, we proposed that an issuer must include as part of its QHP application a narrative justification describing the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing the required information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements (87 FR 76304). We reiterate in this final rule that QHP issuers on the FFEs submit a new application each year and that this information will be part of the annual QHP Certification application submission. Thus, should the size, financial condition, or capabilities of the QHP issuer change such that it believes it can implement one or more of the APIs, that information would be included in the application. We received a few comments on the proposals for exceptions for QHPs.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for the proposed exception process for QHP issuers on the FFEs, highlighting the need for this policy and recommending that CMS finalize the proposal to allow exceptions for QHP issuers on the FFEs regarding compliance with all proposed APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for the policy that QHPs be permitted an exception for the policies that require API development or enhancement in cases where the FFE determines that making such QHPs available is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the QHP issuer to offer QHPs through the FFE. This policy and the exceptions per 45 CFR 156.222(c) are consistent with the exception for QHP issuers on the FFEs 
                        <PRTPAGE P="8906"/>
                        that we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients; we would not want patients to have to go without access to QHP coverage because an issuer is unable to implement these APIs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding the proposed exception process for QHP issuers on the FFEs. Commenters specifically highlighted the ability for a QHP issuer to be certified, even with an exception to these requirements. A commenter recommended that CMS limit using exceptions for QHP issuers on the FFEs for the Provider Access API, and another commenter recommended that CMS explain that QHP issuers on the FFEs must eventually comply with the proposed requirements. A commenter expressed concern that if QHP issuers on the FFEs can be certified without complying with the regulation, then there would not be an incentive for compliance. A commenter stated that the proposal does not make sense given the financial position of QHP issuers on the FFEs and their ability to afford cost-saving technology. The commenter recommended that any exception be conditioned on “no profit taking” by a health plan and limited executive compensation plans until the plan can comply. Additionally, the commenter stated that CMS had not offered a reasonable proposal for criteria to qualify a QHP issuer to be exempt from the proposed API requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand concerns from commenters about permitting delayed implementation of requirements to promote access to information and expedited decision-making. However, given the comments in support of the proposed exceptions process and our interest in ensuring a variety of coverage options for FFE enrollees, we are finalizing this exception as proposed. While some issuers are in a position to implement the updates that this rule requires, a wide range of issuers participate in the FFEs and vary in terms of when they will have available resources to adopt these new requirements. Per applicable rules at 45 CFR 156.221(h), 156.222(c), and 156.223(d), we have been and will continue granting exceptions to QHP issuers on the FFEs on an annual basis, and use information that issuers submit as part of the QHP certification process to track their progress.
                    </P>
                    <P>We will implement the exceptions processes per 45 CFR 156.222(c), and 45 CFR 156.223(d), based on our experience to date with implementing the existing exception per 45 CFR 156.221(h) that is available to QHP issuers on the FFEs that cannot satisfy the requirements per 45 CFR 156.221(a) through (g) to implement and maintain the Patient Access API for the applicable plan year. When determining whether a QHP issuer on an FFE may qualify for an exception to the current requirement to provide a Patient Access API, we take into consideration the content that the issuer submits per the requirement at 45 CFR 156.221(h), including the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. This information allows us to assess whether a QHP issuer has a plan in place to mitigate harm or inconvenience to enrollees by ensuring they can access necessary information, as well as a plan to fully implement the requirements as soon as possible. Information that issuers submit during the QHP certification process also allows us to develop a knowledge base of API development capacity for issuers based on size and other circumstances, which can inform future decisions about whether to allow exceptions. We expect to build on this knowledge base as we implement the exceptions processes per 45 CFR 156.222(c) and 156.223(d), and as part of our updates to the QHP certification process in the coming years to reflect this rule's new requirements, we will continue to work closely with issuers and other stakeholders to ensure that our implementation balances the importance of access to information with robust QHP issuer participation on the FFEs.</P>
                    <P>Finally, QHP issuer applications for plan years 2023 and 2024 indicated that most issuers were compliant with the requirement to provide a Patient Access API. Further, issuers that sought an exception under 45 CFR 156.221(h) generally explained in their justifications that they planned to become compliant with the API requirements mid-way through the upcoming plan year, or shortly after the start of the plan year. This high level of compliance suggests that the availability of an exception does not discourage or de-incentivize issuers' implementation of these standards.</P>
                    <P>We agree that the intent of our final policies is for all impacted payers to provide patients with the benefits of the Provider Access, Payer-to-Payer, and Prior Authorization APIs as soon as they are financially and operationally able. For example, for each of the API provisions for which an exemption is available, we have indicated that if the payer cannot implement the API and is seeking an exemption, it must offer alternative options to the providers to support the intent of the policies; such programs would generally improve the exchange of patient data between payers for care management or access to information for patients, and to improve the prior authorization process for providers and payers. We believe that by requiring alternatives to the APIs during the exemption, payers will investigate options to implement the APIs because, in the long term, these will be more efficient and financially viable than maintaining current manual processes.</P>
                    <P>Table F1 shows the impacted payers that are eligible to apply for an extension, exemption, or exception for the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs required in this final rule. Tables C1, D1, and E4 found in sections II.B., II.C., and II.D. of this final rule include the regulatory citations for the extensions, exemptions, and exceptions for each impacted payer.</P>
                    <GPH SPAN="3" DEEP="239">
                        <PRTPAGE P="8907"/>
                        <GID>ER08FE24.010</GID>
                    </GPH>
                    <HD SOURCE="HD3">3. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs</HD>
                    <P>We explained in the proposed rule for each of the APIs, we would anticipate that states operating Medicaid and CHIP programs would be able to access Federal matching funds to support their implementation of the APIs—specifically, the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We expect these APIs to lead to more efficient administration of Medicaid and CHIP state plans by supporting more efficient data exchange and prior authorization processes, consistent with sections 1902(a)(4) and 2101(a) of the Act, respectively.</P>
                    <P>We do not consider state expenditures for implementing the Provider Access, Payer-to-Payer, or Prior Authorization APIs to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS will not match these expenditures at the state's regular Federal Medical Assistance Percentage (FMAP). However, FFP at a rate of 50 percent could be available for state expenditures related to implementing these APIs for Medicaid programs under section 1903(a)(7) of the Act (for the proper and efficient administration of the Medicaid state plan). The three APIs should, over time, help the state more efficiently administer its Medicaid program by supporting data exchange with providers and other payers and improving efficiencies in the prior authorization process. As we stated in the proposed rule, sharing certain data through the Provider Access API with participating providers could improve the quality of care for patients, using the Payer-to-Payer API may help patients manage their information across payers to support patient care, and using the Prior Authorization API will enable administrative efficiencies by reducing delays in the prior authorization process overall, and by helping reduce the number of denied and appealed prior authorization decisions.</P>
                    <P>States' expenditures to implement the proposed requirements could be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, and installation (DDI) of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with the finalized API requirements.</P>
                    <P>
                        States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described at 45 CFR part 95, subpart F. Additionally, 42 CFR 433.112(b)(12) and 433.116(c) require that any system for which states are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health IT standards adopted at 45 CFR part 170, subpart B. The APIs complement this requirement because they further interoperability by using standards adopted by ONC at 45 CFR 170.215.
                        <SU>151</SU>
                        <FTREF/>
                         States must comply with 42 CFR 433.112(b)(10) and 433.116(c) to explicitly support exposed APIs, meaning the API's functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. We note that FHIR is an open-source standard that can meet the requirements at 42 CFR 433.112(b)(10) and 433.116(c) if implemented by following our regulations, particularly the technical, documentation and denial or discontinuation requirements at 42 CFR 431.60.
                    </P>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             Centers for Medicare and Medicaid Services (2020). SHO # 20-003 RE: Implementation of the CMS Interoperability and Patient Access Final Rule and Compliance with the ONC 21st Century Cures Act Final Rule. Retrieved from 
                            <E T="03">https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Finally, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems within and among states as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state's APIs. Making the needed technical documentation publicly available so that systems that need to do so can connect to the APIs finalized in this rule is required as part of the technical requirements at 42 CFR 431.60(d) for all APIs, including the Provider Access, Payer-to-Payer, and Prior Authorization APIs.
                        <PRTPAGE P="8908"/>
                    </P>
                    <P>Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state's total computable expenditures for a fiscal year (FY), will apply to administrative claims for developing the APIs finalized in this rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed appreciation for the inclusion of language that states may be eligible for enhanced FFP to support implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs in this final rule. While these commenters expressed support for this option, others asked CMS to explain whether enhanced FFP is also available to implement the Patient Access API requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Many states have already requested enhanced Federal matching funds for their expenditures on implementation of the Patient Access API required in the CMS Interoperability and Patient Access final rule. Additionally, enhanced funding under section 1903(a)(3)(A)(i) of the Act may be available for certain expenditures to design, develop, and install the enhancements to the Patient Access API finalized in this rule, in addition to expenditures related to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS encourages states to seek enhanced FFP where it might be applicable for states' expenditures on work needed to meet state Medicaid and CHIP agencies' requirements under this rule and looks forward to reviewing any APDs submitted by states. Instructions for submitting the APDs are available on the Medicaid website 
                        <SU>152</SU>
                        <FTREF/>
                         under the topic of “Medicaid State Plan Amendments” with information about what categories of costs may be included in the requests, such as HIE connection/interface costs. The information on the categories that are included in these requests can be found in the State Medicaid Manual (SMM), Chapter 11, sections 265 &amp; 276,
                        <SU>153</SU>
                        <FTREF/>
                         the State Medicaid Director Letter (SMDL) 16-004, “Mechanized Claims Processing and Information Retrieval Systems-Enhanced Funding,” 
                        <SU>154</SU>
                        <FTREF/>
                         and the State Health Official (SHO) #20-003, “Implementation of the CMS Interoperability and Patient Access final rule.” 
                        <SU>155</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             Code of Federal Regulations (amended 2016, June 2). Retrieved from 45 CFR 95.610, Submissions of advance planning documents.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             Centers for Medicare and Medicaid Services. The State Medicaid Manual (SMM), Chapter 11, sections 265 &amp; 276. Retrieved from 
                            <E T="03">https://www.cms.gov/regulations-and-guidance/guidance/manuals/paper-based-manuals-items/cms021927.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             Centers for Medicare and Medicaid Services (2016, March 31). State Medicaid Director letter #16-004. Retrieved from 
                            <E T="03">https://www.medicaid.gov/sites/default/files/federal-policy-guidance/downloads/SMD16004.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             Centers for Medicare and Medicaid Services (2020, August 14). State Health Official letter #20-003. Retrieved from 
                            <E T="03">https://www.medicaid.gov/sites/default/files/2020-08/sho20003_0.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that states receive a 90 percent Federal match to support implementation of these requirements. Another commenter urged CMS to explain in the final rule, or additional guidance, whether all, or likely all, of the required state investment to develop these APIs, would qualify for enhanced Federal matching to establish and operate API systems.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         States' expenditures to implement the proposed requirements for each of the APIs may be eligible for 90 percent enhanced FFP if the expenditures can be attributed to the DDI for those APIs that benefit the Medicaid program. CMS determines on a case-by-case basis when states' APDs requesting this 90 percent FFP are approvable, consistent with the requirements at 42 CFR part 433, subpart C, and 45 CFR part 95, subpart F. States should work with their MES State Officers for further guidance specific to their programs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS clarify that the Federal funding resources available for states meeting the Prior Authorization API requirement can also include pass-through payments to providers to obtain and utilize interoperable EHR technology for these purposes. This commenter also expressed concern that the proposed rule did not offer any indication of available resources for providers, but they appreciate CMS's clarification of available Federal resources available to states for implementing the Prior Authorization API requirement. Another commenter said that states should be granted flexibility for Federal funding sources to expand the number of SNF providers able to utilize the new Provider Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We encourage states to apply for Federal funding to support their planning, development, and implementation of state systems including the Provider Access, Payer-to-Payer, and Prior Authorization APIs, because these APIs will enable more providers to engage in data exchange with state systems to improve patient care. As previously noted, enhanced Federal Medicaid funding at the 90 percent rate may be available for the DDI and at the 75 percent rate for the operation of these API initiatives that benefit the Medicaid program. These enhanced Federal matching funds, as outlined at 42 CFR 433.112 (DDI) and 433.116 (operation), are available for state expenditures on Medicaid state systems only, and not available for other state or provider expenditures on provider-only systems to support providers' or other entities' efforts to implement APIs. Similarly, Federal matching funds at 50 percent under section 1903(a)(7) of the Act might be available to support Medicaid state specific activities for the required provisions. However, none of these funds are available for funding to providers, as these are designated to support state-specific initiatives.
                    </P>
                    <HD SOURCE="HD3">4. Medicaid Expansion CHIP</HD>
                    <P>Most states have Medicaid expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We proposed and are now finalizing our policy at 42 CFR 457.700(c), that for states with Medicaid Expansion CHIP programs, the final requirements as proposed for Medicaid will apply to those programs rather than separate provisions for the CHIP program. In this final rule, we make explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 apply to the Medicaid expansion CHIP programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that most states have operating Medicaid expansion CHIP programs and that the provisions outlined in the proposed rule would apply to most states.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with this commenter and as stated, are confirming that Medicaid requirements apply equally to Medicaid expansion CHIP programs.
                    </P>
                    <HD SOURCE="HD3">5. Final Action</HD>
                    <P>After consideration of the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our responses to those comments (as summarized), we are finalizing our proposal to allow for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to apply for certain extensions, exemptions, or exceptions for the Provider Access, Payer-to-Payer and/or Prior Authorization APIs. We are also finalizing our proposal regarding Medicaid Expansion CHIP programs.</P>
                    <P>
                        We are finalizing the policy to allow state Medicaid and CHIP FFS programs 
                        <PRTPAGE P="8909"/>
                        to apply for an extension to the deadline from the requirements to implement the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. Specifically, we are finalizing that states may request a one-time, 1-year extension as part of their annual APD for MMIS operations expenditures before the compliance dates. The written extension request must include the following: (1) a narrative justification describing the specific reasons why the state cannot satisfy the requirement(s) by the compliance dates, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program; (2) a report on completed and ongoing state activities that evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the requirements no later than 1 year after the compliance date. CMS will grant an extension if the state establishes, to CMS's satisfaction, that the request adequately establishes a need to delay implementation; and that the state has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.
                    </P>
                    <P>We are finalizing a policy to allow state Medicaid and CHIP FFS programs to apply for an exemption from the requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid MCOs or when at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP MCOs. We are finalizing that the requirements for the Payer-to-Payer API to obtain beneficiaries' permission, provide educational resources at the time of requesting permission, and identify patients' previous/concurrent payers, including for beneficiaries covered under managed care are not eligible for the exemption. Specifically, we are finalizing the policy that a state may request an exemption, as part of their annual APD for MMIS operations expenditures before the compliance date (which may be extended by 1 year if the state receives an extension). The exemption request must include documentation showing that the state meets the threshold criterion based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” (for a Medicaid FFS exemption) or enrollment data from section 5 of the most recently accepted state submission to CHIP Annual Report Template System (CARTS). The state must also include an alternative plan to ensure that providers have efficient electronic access to the same information through other means while the exemption is in effect. CMS will grant the exemption if the state establishes, to CMS's satisfaction, that the state meets the criteria for the exemption, including an alternative plan to ensure efficient electronic access to the same information through other means while the exemption is in effect.</P>
                    <P>We are finalizing that an exemption will expire under two scenarios. First, an exemption will expire if, based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS enrollment data, the State's MCO enrollment for 2 of the previous 3 years is below 90 percent. Second, an exemption will expire if CMS approves a state plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS and/or CHIP CARTS enrollment data.</P>
                    <P>We are finalizing that states must provide written notification to CMS if they no longer qualify for an approved exemption. Written notification must be submitted to CMS within 90 days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP demonstrating the enrollment shift to below 90 percent in managed care. States must obtain CMS approval of a timeline for compliance with the API requirements for Medicaid FFS and/or CHIP FFS within 2 years of the expiration of the exemption. For additional context, please refer to the proposed rule (87 FR 76263).</P>
                    <P>In addition, we are finalizing that for states with Medicaid expansion CHIPs, the requirements for Medicaid will apply to those programs rather than-the provisions for separate CHIPs.</P>
                    <P>We are finalizing that an issuer applying for QHP certification may apply for an exception from requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. The issuer must include, as part of its QHP application, a narrative justification describing the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements. An FFE may grant an exception to the requirements if it determines that making that issuer's QHPs available through the FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception is warranted to permit the issuer to offer QHPs through the FFE.</P>
                    <P>These final policies apply to state Medicaid and CHIP FFS programs and QHP issuers on the FFEs at the CFR sections listed in Tables C1, D1, and E4.</P>
                    <HD SOURCE="HD2">F. Electronic Prior Authorization Measures for the Merit-Based Incentive Payment System Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>As discussed in detail in section II.D. of this final rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. To facilitate those needed improvements in the prior authorization process, we are requiring impacted payers to implement and maintain a Prior Authorization API. The Prior Authorization API aims to improve care coordination and shared decision-making by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. We believe the Prior Authorization API will reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. We also recognize that efficiencies from payer implementation of these APIs will only be realized if they are utilized by requesting providers to complete prior authorization requests.</P>
                    <P>
                        Therefore, we proposed a new measure for MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the MIPS Promoting Interoperability performance category, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization and the Prior Authorization API (87 FR 76312-76314). We proposed the new measures, titled “Electronic Prior Authorization,” to be included in the HIE objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. The Electronic Prior Authorization measure aims to address concerns, specifically from commenters in response to the December 2020 Interoperability proposed rule (85 FR 82586), that few providers would use the Prior 
                        <PRTPAGE P="8910"/>
                        Authorization API established by impacted payers.
                    </P>
                    <P>
                        MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2) and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting Interoperability performance categories. Under 42 CFR 414.1375(b)(2), MIPS eligible clinicians must report on objectives and measures as specified by CMS for the Promoting Interoperability performance category. We refer readers to the CY 2024 Physician Fee Schedule (PFS) final rule (88 FR 79357-79362) for a list of the current objectives and measures required for the MIPS Promoting Interoperability performance category.
                        <SU>156</SU>
                        <FTREF/>
                         We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories during a MIPS performance period for a year. Based on the MIPS eligible clinician's final score, we calculate a MIPS payment adjustment (which can be positive, neutral, or negative) that applies for the covered professional services they furnish in the MIPS payment year which occurs 2 years later.
                    </P>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             In the proposed rule (87 FR 76312), we referred readers to the CY 2023 PFS final rule (87 FR 70075-70080) for the then-current list of objectives and measures. We have updated this final rule to refer to the CY 2024 PFS final rule which includes the most recent objectives and measures, including changes effective for the CY 2024 MIPS performance period.
                        </P>
                    </FTNT>
                    <P>The Medicare Promoting Interoperability Program for eligible hospitals and CAHs is authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory provisions, eligible hospitals and CAHs that are not meaningful EHR users are subject to Medicare payment reductions. To be considered a meaningful EHR user (as defined under 42 CFR 495.4), the eligible hospital or CAH must demonstrate meaningful use of CEHRT by satisfying objectives and measures as required under 42 CFR 495.24. We refer readers to the FY 2024 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (88 FR 59269-59277) for a summary of the currently adopted objectives and measures for the Medicare Promoting Interoperability Program.</P>
                    <HD SOURCE="HD3">2. Electronic Prior Authorization</HD>
                    <P>To support the policies in this final rule and maximize the potential to improve the prior authorization process for providers and patients, we proposed to add new measures, titled “Electronic Prior Authorization,” under the HIE objective of the MIPS Promoting Interoperability performance category and under the HIE objective of the Medicare Promoting Interoperability Program. These measures support the electronic exchange of health information to improve the quality of health care, such as promoting care coordination, as described in section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians, and section 1886(n)(3)(A)(ii) of the Act with respect to eligible hospitals and CAHs.</P>
                    <P>We proposed that for purposes of the Electronic Prior Authorization measures, a prior authorization request must be made using the Prior Authorization API to satisfy the measure, unless the MIPS eligible clinician, eligible hospital, or CAH could claim an applicable exclusion. As discussed in more detail in the proposed rule (87 FR 76313) and further in this section II.F., we proposed that MIPS eligible clinicians, eligible hospitals, and CAHs would report the number of prior authorizations requested electronically via the Prior Authorization API using data from their CEHRT as a numerator and denominator, unless they could claim an applicable exclusion. We proposed that beginning with the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, we proposed that the Electronic Prior Authorization measure would not be scored and would not affect the total score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH would be required to report a numerator of at least one for the measure or claim an exclusion, but the measure would not be scored. We proposed that, if the MIPS eligible clinician or eligible hospital or CAH does not report a numerator of at least one for the measure or claim an exclusion, they would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We noted that we intend to propose a scoring methodology for the measure in future rulemaking.</P>
                    <P>First, we are finalizing that MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), and that eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will allow more time for MIPS eligible clinicians, eligible hospitals, and CAHs to adjust to the new electronic prior authorization workflow using the Prior Authorization API.</P>
                    <P>
                        Second, we are finalizing the Electronic Prior Authorization measure with a modification such that it is structured as an attestation (yes/no) measure, instead of a numerator and denominator measure as originally proposed, for both MIPS eligible clinicians and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a “yes” or “no” response or report an applicable exclusion for the Electronic Prior Authorization measure. Instead of reporting how many times the MIPS eligible clinician, eligible hospital, or CAH requested prior authorization electronically via the Prior Authorization API in a numerator and all prior authorizations in a denominator as proposed (87 FR 76313), the MIPS eligible clinician, eligible hospital, or CAH will either submit an attestation (yes/no) regarding whether they used the Prior Authorization API to submit at least one prior authorization request electronically or claim an applicable exclusion to report the modified Electronic Prior Authorization measures. We are modifying the proposed reporting methodology to align with the modification to the measure specifications we are finalizing, specifically reporting this measure as an attestation yes/no response instead of a numerator and denominator. We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will reduce burden by not requiring MIPS eligible clinicians, eligible hospitals, and CAHs to calculate and report a numerator and 
                        <PRTPAGE P="8911"/>
                        denominator for the Electronic Prior Authorization measure.
                    </P>
                    <P>Additionally, we are finalizing that the measures will not be scored (that is, not assigned points for completion or failure). Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS. This is consistent with our original proposal that failure to report a numerator of at least one for the measure, or claim an exclusion, warrants a zero score for the MIPS Promoting Interoperability performance category and failure to meet Medicare Promoting Interoperability Program reporting requirements (87 FR 76313).</P>
                    <P>
                        For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response on the attestation or claiming an applicable exclusion. A “no” response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR414.1305). MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a “no” response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS.
                        <SU>157</SU>
                        <FTREF/>
                         We note that to report a “yes,” the action of the measure must occur during the selected performance period 
                        <SU>158</SU>
                        <FTREF/>
                         or EHR reporting period,
                        <SU>159</SU>
                        <FTREF/>
                         as per the measure specifications defined below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             
                            <E T="03">See</E>
                             42 CFR 414.1375(a); 414.1380(c)(1).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             
                            <E T="03">See</E>
                             42 CFR 414.1320.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             
                            <E T="03">See</E>
                             42 CFR 495.40(b)(2)(i).
                        </P>
                    </FTNT>
                    <P>
                        For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act.
                        <SU>160</SU>
                        <FTREF/>
                         Eligible hospitals and CAHs that do not meet the minimum program reporting requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             
                            <E T="03">See</E>
                             42 CFR 495.4; 495.24(f)(1)(i)(A).
                        </P>
                    </FTNT>
                    <P>The following is a summary of the comments we received on our proposals and our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for our proposal to add the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs to incentivize use of the Prior Authorization API among providers. Multiple commenters agreed that it is appropriate to place the proposed Electronic Prior Authorization measure under the HIE objective for both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. Multiple commenters noted that the Electronic Prior Authorization measure would incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API capabilities to automate the prior authorization process, which could lead to more timely delivery of care. A commenter stated that this proposal would help ensure that providers utilize the Prior Authorization and Provider Access APIs' technology, in addition to promoting interoperability and the electronic exchange of health information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their feedback and support of the proposed Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We agree that the Electronic Prior Authorization measure will help incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API to automate the prior authorization process, which could lead to more timely delivery of care.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters encouraged CMS to continue to explore additional and alternative opportunities to foster API adoption and utilization of electronic prior authorization tools, as well as incentivize the adoption of the Prior Authorization API across the industry and include a broader set of providers outside of these incentive programs. Commenters suggested expanding the Electronic Prior Authorization measure to other programs to reach additional provider populations, such as the Medicare Shared Savings Program (MSSP) and Alternative Payment Models (APMs). A commenter also recommended implementing a pilot program as part of CMS's Primary Care First (PCF) model. A commenter recommended that CMS should work in partnership with ONC to implement incentives that encourage further adoption of electronic prior authorization. Another commenter supported further development of performance measures to encourage interoperability enhancements and API uptake. A commenter recommended that CMS engage with various associations to encourage further adoption. A commenter supported industry-wide adoption of electronic prior authorization processes but suggested that only requiring impacted payers to build APIs would not lead to broad adoption. A commenter stated that CMS should use every available option to influence and incentivize adoption of these standards within the health care industry if it intends to mandate that impacted payers participate. Commenters also acknowledged that the provider community is an important, interested group in the drive to enable widespread interoperability.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their support and additional recommendations on how we can incentivize using the Prior Authorization API. We will continue to monitor and assess opportunities we can leverage to encourage API implementation uptake. Additionally, we will continue to collaboratively work with ONC to identify ways to incentivize the adoption of electronic prior authorization. We believe that establishing the Electronic Prior Authorization measure is a viable method to begin fostering the adoption and utilization of the Prior Authorization API by MIPS eligible 
                        <PRTPAGE P="8912"/>
                        clinicians, eligible hospitals, and CAHs in these initiatives. We note that nothing in the Prior Authorization API proposal we are finalizing would prohibit providers that are not subject to MIPS or the Medicare Promoting Interoperability Program from using the API for electronic prior authorization as well. Where permitted under applicable law and relevant program requirements, we encourage providers who are not included in these programs to leverage the Prior Authorization APIs to gain the intended benefits, such as improving efficiency and reducing the administrative burden of prior authorization processes. We agree that requiring impacted payers to build the APIs would not lead to broad adoption. However, we believe that establishing the Electronic Prior Authorization measure under both MIPS and the Medicare Promoting Interoperability Program will help promote the implementation and use of the Prior Authorization API by MIPS eligible clinicians, eligible hospitals, and CAHs. In order for the industry to realize the efficiencies of the Prior Authorization API and achieve the goals set forth in this final rule, it is essential that both impacted payers and providers adopt and use a Prior Authorization API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters opposed adoption of the proposed Electronic Prior Authorization measure stating that the measure would be inefficient and burdensome, citing challenges with additional workflow requirements, increased provider burden, and financial burden. A commenter stated that it would potentially leave providers unfairly penalized. Several commenters noted that the burden of reporting outweighs the benefits of use and that hospital IT resources are already overloaded and limited. Other commenters noted that mandating the Electronic Prior Authorization measure could further increase provider burden and detract from patient care, directing MIPS eligible clinicians, eligible hospitals, and CAHs' attention away from patients. A commenter stated that the Electronic Prior Authorization measure proposal is unlikely to provide significant relief to providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs). Another commenter stated that payers should compensate providers fairly for the cost of each prior authorization for the implementation of costly and burdensome electronic prior authorization requirements. This commenter stated that each prior authorization is a net financial loss for practices. Another commenter recommended that the Electronic Prior Authorization measure should remain optional until a time when the benefit, both monetarily and in reduced administrative burden, can be quantified for a calculated return on investment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the feedback provided by commenters and note that we believe the benefit of the Prior Authorization API will outweigh the burden of implementation. We refer readers to the Collection of Information (COI) requirements in section III. of this final rule regarding burden and the regulatory impact analysis (RIA) we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We acknowledge that there is an initial implementation and data collection burden associated with the Electronic Prior Authorization measure. However, we believe that the benefits of using an electronic prior authorization process outweigh the burdensome manual process used today. We believe that making the prior authorization process electronic will improve the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. We emphasize that we are implementing requirements for both impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) to help streamline the prior authorization process because both payers and providers have a role to play in this process and the solution cannot be one-sided. As discussed further in this section, in order to address concerns regarding the burden of the Electronic Prior Authorization measure on MIPS eligible clinicians, eligible hospitals, and CAHs, we are modifying the measure to be an attestation (yes/no) measure rather than a numerator and denominator measure. Therefore, data collection to report a numerator and denominator for the Electronic Prior Authorization measure is no longer required.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter cautioned that the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category would reflect data regarding a different population than other MIPS measures, stating that other measures in MIPS are designed to capture information about the Medicare beneficiary population specifically. The commenter stated that this would make these measures difficult to compare. Another commenter stated that the Electronic Prior Authorization measure proposed for the MIPS Promoting Interoperability performance category does not apply to Medicare FFS, which results in misalignment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback. First, we disagree that the Electronic Prior Authorization measure will reflect data regarding a different population than other MIPS measures. We note that all of the MIPS Promoting Interoperability performance category measures are based on using CEHRT, utilizing data that are captured in the CEHRT, and require submission of applicable data, regardless of payer. The Electronic Prior Authorization measure is consistent with other measures reported under the MIPS Promoting Interoperability performance category.
                    </P>
                    <P>Second, although Medicare FFS is not an impacted payer, we refer readers to section I.D.1. of this final rule where we discuss CMS's intent to align Medicare FFS to the requirements of this final rule, as applicable. Although, generally, the policies in this final rule do not directly pertain to Medicare FFS, we want to ensure that Medicare beneficiaries, as well as other individuals, can benefit from these policies, regardless of their coverage, delivery system, or payer.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that, if CMS does move forward with the proposed Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category, CMS should consider exempting small, rural, and underserved practices from reporting the Electronic Prior Authorization measure, which would redistribute the Promoting Interoperability performance category's weight to other performance categories. A few commenters suggested that the inclusion of the Electronic Prior Authorization measure would have a disproportionately adverse effect on small business entities, federally recognized American Indian and Alaska Native-Tribal communities, psychiatric practices, and other specialties and could contribute to the electronic divide.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their feedback and would like to note that there are a number of situations in which MIPS eligible clinicians may qualify for reweighting of the MIPS Promoting Interoperability performance category. This includes policies implemented in our regulations at 42 CFR part 414, subpart O, including 42 
                        <PRTPAGE P="8913"/>
                        CFR 414.1380(c)(2), if they have a special status (defined at 42 CFR 414.1305), are a qualifying clinician type, or have a CMS-approved significant hardship or other exception application. For example, MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(
                        <E T="03">9</E>
                        ), and therefore would not be required to meet the MIPS Promoting Interoperability performance category's requirements including reporting on this Electronic Prior Authorization measure (86 FR 65485-65487). If the MIPS Promoting Interoperability performance category is reweighted to zero percent as provided at 42 CFR 414.1380(c)(2)(i), the category's 25 percent weight will be redistributed to the remaining MIPS performance categories in accordance with 42 CFR 414.1380(c)(2)(ii).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters opposed the proposed addition of the Electronic Prior Authorization measure. Commenters believed that the finalization of the Electronic Prior Authorization measure would not be necessary because MIPS eligible clinicians, eligible hospitals, and CAHs would be prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which likely would reduce provider burden, improve prior authorization processing time, and enable more timely access to care. Multiple commenters expressed that they do not believe that the proposed Electronic Prior Authorization measure would address concerns about low provider utilization of APIs, especially for small, rural providers, due to cost, limited bandwidth, and lack of dedicated health IT staff. A commenter expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Some commenters stated that, as electronic prior authorization becomes more common and affordable, providers would be incentivized to adopt this process, which promises to free up resources and allow providers to spend more time on patient care. A commenter stated that providers will be naturally incentivized to engage in electronic prior authorization processes if the processes lower costs, carry a minimal burden, do not cause unreasonable delays in care, and lead to care that is in their patients' best interests. Another commenter stated that the proposal to add a measure on conducting electronic prior authorization for items or services using the Prior Authorization API is not sufficient to encourage robust use of the Prior Authorization API by providers and stated that the proposals will be a one-sided mandate on impacted payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' feedback and are glad to hear that providers likely would be naturally incentivized and prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which we believe it will. However, based on experience with adoption of other similar new EHR technology, we believe there needs to be an initial drive to encourage all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to support widespread adoption, thus reaping the benefits of burden reduction through the electronic prior authorization processes. We understand and agree that the Electronic Prior Authorization measure itself may not be enough to address concerns about low provider utilization of APIs, particularly for small and rural providers. However, we believe the improvement and benefits in the prior authorization processes resulting from using the Prior Authorization API, specifically, may encourage such providers to adopt the API to help streamline existing paper-based or portal-based processes.
                    </P>
                    <P>
                        We acknowledge that small, rural providers may have limited bandwidth and fewer dedicated IT staff. We note that implementing an electronic prior authorization process could free up resources and allow providers to spend more time on patient care, which can be a challenge for small, rural providers. We also note that MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(
                        <E T="03">9</E>
                        ), and therefore would not be required to meet the category's requirements including reporting on this Electronic Prior Authorization measure (86 FR 65485-65487). We believe that using electronic prior authorization processes will benefit small, rural providers, and small practices in underserved communities who are able to implement and maintain the Prior Authorization API in their processes with by saving time, faster turnaround on prior authorization requests, and, in turn, improved patient satisfaction.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS calculate the additional cost of compliance with the MIPS requirements generally and consider what benefit MIPS reporting offers when practices already have a great interest in lowering their expenses related to prior authorization.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's feedback regarding cost of the Electronic Prior Authorization measure and refer readers to the RIA we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We note that the cost of compliance and benefits of reporting for MIPS as a whole are outside the scope of this rule. We will continue to evaluate use of the Prior Authorization API and assess whether the Electronic Prior Authorization measure has achieved its goal of promoting widespread Prior Authorization API adoption.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters acknowledged that the proposed Electronic Prior Authorization measure is not directed toward the impacted payers. A commenter stated that CMS should collect prior authorization data from payers to measure their performance rather than from providers. Another commenter noted that the electronic prior authorization proposal does not assess any financial costs against payers to discourage their overuse of prior authorizations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback and acknowledge that this Electronic Prior Authorization measure is not intended to incentivize payers to use the Prior Authorization API. For more information about the Prior Authorization API requirements for payers, we refer readers to section II.D. of this final rule.
                    </P>
                    <P>
                        To reiterate, the success of the Prior Authorization API is dependent upon both payers and providers using the Prior Authorization API. We want to stress the importance of both payers and providers using the Prior Authorization 
                        <PRTPAGE P="8914"/>
                        API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build, implement, and maintain the API, but also to drive MIPS eligible clinicians, eligible hospitals, and CAHs to use it.
                    </P>
                    <P>We agree that collecting prior authorization data from payers is important and provides accountability for using prior authorization processes. As such, we are finalizing our proposal to require payers to publicly report certain prior authorization metrics. We refer readers to section II.D. of this final rule for further information on these requirements for impacted payers.</P>
                    <P>We note that prior authorization is an established administrative process used by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided. The policies we are finalizing are not intended to discourage the use of prior authorization, nor do they impose direct financial repercussions for using prior authorization by payers. The policies we are finalizing in this final rule are intended to streamline the existing prior authorization process.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters noted that the adoption of the Electronic Prior Authorization measure contradicts CMS's goal of reducing provider burden and urged CMS not to replace one type of administrative burden with another. Another commenter cautioned that the proposed Electronic Prior Authorization measure is not suitable for a quality improvement program given that the focus is on technological capability. A commenter stated that measures related to prior authorization conflict with the goal of MIPS to improve quality of health care, stating there is no evidence to indicate that prior authorization improves outcomes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We disagree that the Electronic Prior Authorization measure conflicts with our goals and believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future. We believe this measure is entirely suitable for MIPS since the goal of MIPS is to provide financial incentives to clinicians that provide high-value and high-quality care to Medicare patients. MIPS supports care improvements by focusing on better patient outcomes and decreasing clinician burden. We believe that electronic prior authorization aligns with these goals, as it streamlines a historically burdensome process to allow providers to spend more time focused on improving patient outcomes instead of administratively burdensome processes.
                    </P>
                    <P>We also believe that the Electronic Prior Authorization measure fits within the goals of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category by enhancing the meaningful use of CEHRT. For the MIPS Promoting Interoperability performance category, section 1848(q)(2)(B)(iv) of the Act requires MIPS eligible clinicians to report on specified measures and activities demonstrating that they meet the requirements established under section 1848(o)(2) of the Act for determining whether the MIPS eligible clinician is a meaningful EHR user. For the Medicare Promoting Interoperability Program, section 1886(n) of the Act similarly requires eligible hospitals and CAHs to demonstrate that they meet requirements established under section 1886(n)(3)(A) (which align with section 1848(o)(2)(A) of the Act) for determining whether the eligible hospital or CAH is a meaningful EHR user. Electronic exchange of information to improve health care and care coordination is a central statutory requirement for both the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.</P>
                    <P>We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and the Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure will further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modifications, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). We believe the Electronic Prior Authorization measure is another means by which MIPS eligible clinicians, eligible hospitals, and CAHs, can use their health IT to timely and efficiently share key health information with payers to obtain prior authorizations promptly and thereby provide necessary health care to their patients expeditiously. Therefore, we believe the Electronic Prior Authorization measure does meet the intended goal of these programs to promote interoperability and electronically exchange health information.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters opposed the Electronic Prior Authorization measure stating that prior authorizations are a harmful practice that result in delays and denials of necessary care which can worsen a patient's condition. Several commenters shared concerns about payer prior authorization policies themselves. A commenter stated that prior authorizations lower the costs for payers but raise the overall cost of care by delaying care and shifting costs to providers and patients, thus worsening clinical outcomes which necessitates the escalation of more expensive care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We would like to thank commenters for their feedback regarding payers' prior authorization processes and the burden placed on patients and providers. We understand that some commenters expressed concerns about prior authorization itself, regardless of whether it could be completed electronically, and whether or not these existing prior authorization requirements support improved outcomes. We note that the existence and use of prior authorization processes is outside the scope of this rule. Our policies are limited to streamlining this already existing process.
                    </P>
                    <P>The policies we are finalizing in this rule are not intended to encourage or discourage the prior authorization requirements that payers already have; these policies are intended to increase the efficiency of these existing requirements and processes by encouraging use of electronic methods. We understand that the existing prior authorization process can be burdensome, and thus believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future.</P>
                    <P>We received many comments on the December 2020 CMS Interoperability proposed rule, which has since been withdrawn, and in response to the CMS Interoperability and Prior Authorization proposed rule that indicated that prior authorization processes could be improved by electronic, interoperable data exchange. Those comments have informed the policies we are finalizing in this rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that the Electronic Prior Authorization measure should not penalize LTCHs and Inpatient Rehabilitation Facilities (IRFs) for 
                        <PRTPAGE P="8915"/>
                        failing to use EHRs. Another commenter expressed that practices have many different technical and infrastructure capabilities; therefore, they recommended that CMS consider ways to further engage and support all provider types—especially safety-net, small/independent, and/or rural health providers—to adopt and use the Prior Authorization API. The commenter continued by stating that they are concerned that these providers are at risk of being left behind. Likewise, the commenter stated that CMS should also explore ways to expand provider incentives to reach broadly across the health care system to encourage widespread adoption of the Prior Authorization API. Another commenter recommended that CMS include all health care providers as recipients of the benefits of the final rule, whether they are recipients of Meaningful Use dollars or are participants in MIPS. The commenter continued by providing a possible scenario in which payers further delay decisions of excluded providers in favor of meeting the requirements for providers included under the provisions of the rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that LTCHs and IRFs are not included in the definition of an eligible hospital or CAH (42 CFR 495.4 definitions, 75 FR 44327) and therefore would not be required to report the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program.
                        <SU>161</SU>
                        <FTREF/>
                         We also understand that different practices have different technical and infrastructure capabilities. To the extent that these facilities or any provider type ordering items or services requiring prior authorizations have access to appropriate health IT and the Prior Authorization API and are otherwise permitted to use the Prior Authorization API, we encourage them to use this technology for their own benefit. Our proposals for the Prior Authorization API technology and functionality do not limit its use to participants under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We will continue to look for ways to encourage API implementation uptake and ways to incentivize the adoption of electronic prior authorization across additional programs and provider types, especially safety-net, small/independent, and rural health providers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             Centers for Medicare and Medicaid Services (2023, September 6). Medicare Promoting Interoperability Program: Eligibility Hospital Information. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Eligibility-#BOOKMARK2.</E>
                        </P>
                    </FTNT>
                    <P>Additionally, we appreciate the comment regarding possible scenarios in which impacted payers further delay decisions on prior authorizations from providers not participating in MIPS or the Medicare Promoting Interoperability Program or not using the Prior Authorization API. However, to mitigate this, we are finalizing certain prior authorization decision timeframes for all impacted payers. We refer readers to section II.D. of this final rule for more information on the prior authorization decision timeframe provisions.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that instead of developing the Electronic Prior Authorization measure, CMS should engage in stringent oversight to ensure that impacted payers are not only developing and implementing a Prior Authorization API but are also implementing all of the provisions of this final rule. The commenter also suggested that CMS should release additional information on how it will enforce the proposed requirements contained in the CMS Interoperability and Prior Authorization proposed rule to ensure compliance.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As explained in the proposed rule, and in the CMS Interoperability and Patient Access final rule, each program oversees compliance under existing program authorities and responsibilities. These compliance processes vary among programs and may have different implications based on a payer's status in the program, previous compliance actions, and corrective action. Patients and providers should submit an inquiry or complaint to the appropriate program, depending on their coverage as described in section I.D.2. of this final rule. Compliance questions or complaints about compliance may be sent to the respective program contact at the website or email address provided there. Compliance will be tracked through specific methods managed by the programs. While these compliance efforts will help payer compliance, as we have stated repeatedly throughout this section, it is imperative that both payers and providers come together to use the Prior Authorization API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build the Prior Authorization API, but also to incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use it through the finalization of this Electronic Prior Authorization measure.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that CMS lacks a legitimate justification for imposing the new Electronic Prior Authorization measure, as it does not align with the legal requirements under section 1848(q) of the Act. The commenter sought clarification on how the proposed measure complies with the governing regulations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We have authority under section 1848(q)(2)(A)(iv) and (B)(iv) of the Act, which requires that we assess MIPS eligible clinicians' performance with respect to their meaningful use of CEHRT in accordance with the requirements established in section 1848(o)(2) of the Act. We also have authority under section 1848(q)(2)(B)(iv) of the Act to create new measures under the MIPS Promoting Interoperability performance category as well as for determining whether an eligible professional is a meaningful EHR user in accordance with the requirements established in section 1848(o)(2) of the Act. Connecting to the API technology identified in the Electronic Prior Authorization measure helps to facilitate bi-directional data exchange electronically and can significantly reduce the burden associated with the prior authorization processes for providers using data from CEHRT when accessing the Prior Authorization API. This type of function demonstrates meaningful use of CEHRT and is therefore appropriate in assessing whether a MIPS eligible clinician is a meaningful EHR user under section 1848(o)(2)(A) of the Act.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS use its authority to permit payers to include quality measures tied to use of the APIs in the provider contracts.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's recommendation. However, we leave this decision—whether payers require measures like this for their providers and how they work with their providers on using the Prior Authorization API—up to the discretion of the payers.
                    </P>
                    <HD SOURCE="HD3">a. Measure Specifications</HD>
                    <P>
                        In the proposed rule (87 FR 76313), we proposed the following specifications for the Electronic Prior Authorization measure: 
                        <SU>162</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             In the proposed rule, we used the term “Prior Authorization Requirements, Documentation, and Decision API (PARDD API).” For simplicity, we are finalizing the name of that API as simply the “Prior Authorization API.”
                        </P>
                    </FTNT>
                    <PRTPAGE P="8916"/>
                    <HD SOURCE="HD3">1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization</HD>
                    <P>
                        • 
                        <E T="03">Measure Description:</E>
                         For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically from a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>The MIPS eligible clinician would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:</P>
                    <P>
                        • 
                        <E T="03">Denominator:</E>
                         The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered by the MIPS eligible clinician during the performance period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule.
                    </P>
                    <P>
                        • 
                        <E T="03">Numerator:</E>
                         The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>
                        • 
                        <E T="03">Exclusion:</E>
                         Any MIPS eligible clinician who:
                    </P>
                    <P>(1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or</P>
                    <P>(2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule during the applicable performance period.</P>
                    <HD SOURCE="HD3">2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program—Electronic Prior Authorization</HD>
                    <P>
                        • 
                        <E T="03">Measure Description:</E>
                         For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>The eligible hospital or CAH would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:</P>
                    <P>
                        • 
                        <E T="03">Denominator:</E>
                         The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered for patients discharged from the eligible hospital or CAH inpatient or emergency department (POS code 21 or 23) during the EHR reporting period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule.
                    </P>
                    <P>
                        • 
                        <E T="03">Numerator:</E>
                         The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>
                        • 
                        <E T="03">Exclusions:</E>
                         Any eligible hospital or CAH that—
                    </P>
                    <P>++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting; or</P>
                    <P>++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule during the applicable EHR reporting period.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposal regarding the proposed Electronic Prior Authorization measure's numerator and denominator criteria. Specifically, a commenter agreed with the numerator being the number of unique prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT if the Electronic Prior Authorization measure includes electronic prior authorizations from commercial payers. A commenter recommended that CMS ask for the percentage of prior authorization requests that are not being completed through the Prior Authorization API. Another commenter supported CMS's proposal to include prior authorization requests that are made using fax, mail, or portal in the denominator of the Electronic Prior Authorization measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case it would be excluded from the denominator. A commenter expressed support for CMS progressing the proposed Electronic Prior Authorization measure to a performance-based measure in future years.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback and appreciate their support for the numerator and denominator criteria for the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We agree that requiring participants to report a numerator and denominator for the measure would ultimately give us the most insight into the degree of adoption and use of the Prior Authorization API. However, after consideration of comments received, and as discussed in more detail later in this section, we are modifying the specifications of the Electronic Prior Authorization measure to require an attestation (yes/no), in lieu of reporting data for a numerator and denominator as proposed, for this measure beginning with the CY 2027 performance period/2029 MIPS payment year for MIPS and the CY 2027 EHR reporting period for the Medicare Promoting Interoperability Program.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS explore different mechanisms for tracking electronic prior authorization requests. A few commenters also noted that tracking these data elements should be the responsibility of payers, as they would have this information more easily accessible. Another commenter stated that CMS needs to determine an approach to measure the usage of electronic prior authorization tools that does not require collecting information about the availability of corresponding APIs or functionality. Another commenter stated that measuring the success of these policies should not be punitive for providers and that the metrics of success should exist for all stakeholders. Multiple commenters urged CMS to work with the provider community, as well as other stakeholders, on various aspects of the Electronic Prior Authorization measure as well as other prior authorization reforms to identify ways to incentivize provider uptake without creating unnecessary provider burden and determine how to engage providers in the testing and development of the proposed Electronic Prior Authorization measure. Another commenter noted that the technology supporting electronic prior authorization must be widely available and demonstrated to be effectively integrated into EHR workflows through real-world testing prior to requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report on use of the Prior Authorization API for the Electronic Prior Authorization measure. A commenter suggested that CMS should require payers to provide these data on electronic prior authorization, rather than place increasing demands on providers.
                        <PRTPAGE P="8917"/>
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their recommendations. We will consider exploring additional mechanisms for tracking electronic prior authorization requests in future rulemaking. We believe that tracking the use of electronic prior authorization processes by impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) is important to ensure widespread implementation and use of the Prior Authorization API by both user groups. In this context, we view the Electronic Prior Authorization measure not merely as a way to track performance or success. Instead, we view this measure as a way for MIPS eligible clinicians, eligible hospitals, and CAHs to adopt and use the electronic Prior Authorization APIs implemented by payers. As we have noted previously, payers impacted by this rule are required to implement and maintain the Prior Authorization API. To fully recognize the benefits and efficiencies of payer implementation of this API, we need to encourage providers to use said API to complete prior authorization requests. While we are encouraged by commenters' statements that the benefits of the Prior Authorization API are enough to encourage providers to use it, we also believe that accessing this API using data from CEHRT demonstrates meaningful use of CEHRT that can improve patient care under sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, and thus believe this measure is appropriate to incentivize providers to adopt and use this technology. We refer readers to section II.D. of this rule where we discuss in further detail the metrics impacted payers will be required to report on electronic prior authorizations.
                    </P>
                    <P>
                        We note that we do not currently use established workgroups to test and develop measures for the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category outside of our annual call for measures.
                        <SU>163</SU>
                        <FTREF/>
                         We do work with members of the provider community in HL7 workgroups to obtain their feedback during the development and testing phases of the IGs that support the Prior Authorization API, as well as during discussions around technical workflow. We encourage providers to engage in the HL7 FHIR workgroup meetings to get involved in the standards development and implementation discussions for specific use cases. The IGs are also tested during Connectathons and throughout the IG development lifecycle and refined based on testing and implementation feedback. We have also previously reviewed public comments received on the Reducing Burden and Improving Electronic Information Exchange of Prior Authorizations RFI (85 FR 82639) and December 2020 CMS Interoperability proposed rule (85 FR 82586) regarding ways in which we could incentivize and encourage provider use of the electronic Prior Authorization API and used that feedback to develop our policies outlined in this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             Centers for Medicare and Medicaid Services. (2023, September 6). Annual Call For Measures. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/CallForMeasures.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed their disapproval of the proposed Electronic Prior Authorization measure's numerator and denominator criteria. Numerous commenters stated that the Electronic Prior Authorization measure as proposed would create significant data collection and reporting burden on MIPS eligible clinicians, eligible hospitals, CAHs, and support staff. Many commenters specifically identified the excessive burden with calculating the denominator. Multiple commenters expressed concern regarding identifying which prior authorization requests meet the denominator requirements of the proposed Electronic Prior Authorization measure (for example, which payers offer a Prior Authorization API or how a provider will be able to determine the number of prior authorization requests that should be counted in the denominator) making this measure particularly burdensome, contributing to provider burnout, and causing further delays in care. A commenter sought clarification on whether CMS is considering alternatives to the proposed numerator and denominator measure criteria and requested changes to these specifications that would reduce the implementation burden for both providers and health IT developers.
                    </P>
                    <P>Some commenters expressed concern regarding compliance and documentation for the proposed Electronic Prior Authorization measure. Commenters stated that providers submit prior authorizations in a variety of modalities and noted it will be hard to track all prior authorizations submitted. Other commenters expressed similar concerns given that data surrounding prior authorizations are captured outside of an EHR, which would make the data collection process extremely burdensome.</P>
                    <P>Several commenters urged CMS not to implement the Electronic Prior Authorization measure as proposed due to these concerns or consider ways the measure could be implemented without increasing provider burden. A commenter recommended that CMS continue to evaluate the numerator and denominator proposals and adjust the requirements based on real-world testing. Another commenter questioned why CMS would create a numerator/denominator measure that is not automatically calculated by EHRs. The commenter continued by stating that several EHR vendors will likely not have the capability to assist in tracking prior authorization requests for reporting purposes. Another commenter disagreed with the proposed measure criteria to collect information on the total number of prior authorization requests submitted by the Prior Authorization API versus other request methods given that collecting these data does nothing to improve patient clinical outcomes. Therefore, multiple commenters recommended that CMS should use an attestation (yes/no) measure and remove the proposed numerator/denominator criteria.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters sharing their concerns regarding the burden associated with calculating a numerator and denominator as proposed for the Electronic Prior Authorization measure. Generally, we proposed that to report these measures, MIPS eligible clinicians, eligible hospitals, and CAHs must use data from their CEHRT to request prior authorization from a payer for at least one medical item or service (excluding drugs), and, for eligible hospitals and CAHs, one hospital discharge and medical item or service that they ordered via the Prior Authorization API (87 FR 76313). However, we recognize that the challenge of consistently calculating a numerator and denominator for these proposed measures across providers increases if providers are accessing the Prior Authorization API in different ways. We further recognize that it would be challenging for MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for these measures as we proposed until such time as the ONC Health IT Certification Program establishes health IT certification criteria to support standardized exchange via the Prior Authorization API and adopts updated certification criteria supporting numerator and denominator calculation.
                    </P>
                    <P>
                        We acknowledge that modifying the Electronic Prior Authorization measure to be attestation-based would substantially reduce the reporting burden placed on MIPS eligible clinicians, eligible hospitals, and CAHs. 
                        <PRTPAGE P="8918"/>
                        With an attestation-based yes/no measure, those providers would be required to report a yes/no response, rather than a numerator and denominator, to indicate whether they used a Prior Authorization API to submit at least one electronic prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail later in this section, we are modifying the Electronic Prior Authorization measure to be an attestation measure, meaning that MIPS eligible clinicians, eligible hospitals, and CAHs will report a yes/no response for the measure. We will continue to explore ways to move toward numerator and denominator reporting for future years of the measure, particularly should ONC Health IT Certification Program criteria be made available to support certification of EHRs to the capability associated with tracking prior authorizations requested electronically via the Prior Authorization API using data from CEHRT.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the Electronic Prior Authorization measure should not be restricted only to items and services but should also include drugs to provide consistency across prior authorization needs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed earlier in this final rule, the Prior Authorization API requirements we have finalized for impacted payers are limited to medical items and services (excluding drugs). Therefore, for consistency, we are aligning using the API for the Electronic Prior Authorization measure to limit it to evaluating using a Prior Authorization API for medical items and services authorization requests only. We refer readers to section II.D. for additional information on the Prior Authorization API requirements for impacted payers and the exclusion of drugs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that industry would need to review and endorse the specification criteria prior to requiring the Electronic Prior Authorization measure.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for this suggestion; however, we must note that there is no requirement for industry to review or endorse measures in either the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. We welcome comments from any interested parties through public comment during rulemaking, and also during the annual call for measures for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, every summer.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern that MIPS eligible clinicians, eligible hospitals, and CAHs will not have the necessary health IT to support the Prior Authorization API and therefore will not be able to report the proposed Electronic Prior Authorization measure by the proposed implementation year of CY 2026. Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization, the Prior Authorization API is implemented, and workflow is established. A commenter stated that providers should have the flexibility to stage their adoption, as recognized in the Electronic Prior Authorization measure proposal, to support a smooth transition from the current, manual process to a fully electronic workflow. Another commenter suggested that CMS needs to provide eligible hospitals with adequate time to convert their current processes into an electronic prior authorization process prior to implementing the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program. The commenter expressed their concern that this transition to a new electronic process will allow cases to fall through the cracks.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback. After reviewing comments for both the Prior Authorization API and for using that API in this Electronic Prior Authorization measure, we reconsidered our proposal and agree that provision of additional time for implementation would be beneficial. As previously discussed, we understand that there may be challenges with the availability of health IT to calculate a measure numerator and denominator consistently for the Electronic Prior Authorization measures as we originally proposed. We also believe the functionality of the Prior Authorization API should be in place and used by hospitals and providers prior to requiring a numerator and denominator be reported. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. As noted previously, the Unified Agenda, current at the time of this final rule's publication, includes an entry for a proposed rule from ONC (RIN 0955-AA06). The description indicates that that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.
                        <SU>164</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>As previously discussed, we are finalizing the Electronic Prior Authorization measure with modification, to delay implementation for a year later than originally proposed, beginning with CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians in the MIPS Promoting Interoperability performance category, and beginning with the CY 2027 EHR reporting period for eligible hospitals and CAHs under the Medicare Promoting Interoperability. This modification also aligns with the finalized compliance dates in 2027 for the Prior Authorization API. Also, as previously discussed, we are finalizing the Electronic Prior Authorization measure with modification as an attestation (yes/no) measure, instead of requiring reporting of data for a numerator and denominator. We believe this modification will minimize data collection and reporting burden for this measure.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters recommended that the Electronic Prior Authorization measure be an attestation (yes/no) measure to mitigate provider burden if CMS moves forward with the proposed measure. Some commenters stated that they are not opposed to the Electronic Prior Authorization measure and appreciated CMS not scoring it initially. However, a commenter noted there may be implementation challenges due to eligible hospitals and CAHs still recovering from the PHE and not having enough resources to implement. Another commenter suggested that the Electronic Prior Authorization measure remain unscored indefinitely. The commenter noted that the Prior Authorization API still being in the pilot testing phase is an additional challenge. Another commenter expressed their appreciation for the implementation timeline of the Electronic Prior Authorization measures stating that it would allow for technical implementation, provider implementation, and education. Multiple commenters were displeased with the proposed scoring methodology for the Electronic Prior Authorization measure. Multiple commenters recommended that CMS consider making the Electronic Prior 
                        <PRTPAGE P="8919"/>
                        Authorization measure voluntary or award bonus points for the proposed Electronic Prior Authorization measure rather than including the measure in the composite score. A commenter stated that an attestation (yes/no) measure would align the proposed Electronic Prior Authorization measure with the other measures within the HIE objective.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations on ways to ease burden by making the Electronic Prior Authorization measure an attestation (yes/no) measure. We agree and acknowledge that it would significantly reduce the reporting burden for MIPS eligible clinicians, eligible hospitals, and CAHs if we did not require a numerator and denominator to be calculated, and instead require only a “yes” or “no” response be reported to indicate whether the Prior Authorization API was used for at least one prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail elsewhere in this section, we are modifying the proposed Electronic Prior Authorization measure to be reported as an attestation (yes/no) measure.
                    </P>
                    <P>We appreciate the commenters' recommendations for scoring this measure, such as not scoring the measure or only assigning bonus points. However, we respectfully disagree with these approaches. First, we did not propose to score this measure by assigning points (for example, between 10 and 30 points for successful completion as provided at 42 CFR 414.1380(b)(4)(ii) for MIPS). However, we did propose that a MIPS eligible clinician, eligible hospital, or CAH would “receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program” if they did not “report a numerator of a least one for the measure or claim an exclusion” (87 FR 76313). In other words, we proposed that if a MIPS eligible clinician, eligible hospital, or CAH failed to request at least one prior authorization electronically via the Prior Authorization API using data from their CEHRT, as would be required to report a numerator under the originally proposed measure specifications (attesting “no” to the measure), or claim an applicable exclusion, then they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the Promoting Interoperability performance category. A failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the MIPS Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS.</P>
                    <P>Second, we clarify our rationale for proposing this scoring policy of zero for this measure, which we are finalizing with modification to align with the attestation-based measure specifications we are finalizing in this section. Fundamentally, a MIPS eligible clinician, eligible hospital, or CAH must demonstrate it is a meaningful EHR user by meeting three statutory criteria set forth in sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, to earn a score for the MIPS Promoting Interoperability performance category (section 1848(q)(2)(B)(iv) of the Act) or avoid a downward payment adjustment for the Medicare Promoting Interoperability Program. We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure would further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modification, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). A MIPS eligible clinician, eligible hospital, or CAH using the Prior Authorization API to request at least one prior authorization electronically for, or claiming an applicable exclusion from, reporting this measure, fundamentally demonstrates that they are a meaningful EHR user. Therefore, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates they are not a meaningful EHR user and warrants the MIPS eligible clinician, eligible hospital, or CAH receiving a score of zero for the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program.</P>
                    <P>After consideration of public comments we received, we are finalizing a modification to our proposal that the Electronic Prior Authorization measure will require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator, and instead, require that MIPS eligible clinicians, eligible hospitals, and CAHs attest “yes” or “no” to having performed at least one electronic prior authorization using the Prior Authorization API, or claim an applicable exclusion. We are also finalizing that, if a MIPS eligible clinician, eligible hospital, or CAH attests “no” or fails to claim an applicable exclusion for this measure, then they will receive a zero score for the MIPS Promoting Interoperability performance category (currently worth 25 percent of their final score for MIPS) or fail to meet Medicare Promoting Interoperability Program reporting requirements. To allow for additional implementation time, we are finalizing inclusion of the Electronic Prior Authorization measure in the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and in the Medicare Promoting Interoperability program beginning with the CY 2027 EHR reporting period.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters expressed concerns that providers may be unfavorably evaluated or unfairly penalized for infrastructure and system issues or lack of capabilities and not the providers' willingness or desire to conduct electronic prior authorizations. A commenter requested clarification on the proposed measure exclusion criteria applying only to medical items and services (excluding drugs) requiring prior authorization from a payer that does not offer a Prior Authorization API, questioning whether this exclusion would lead to unintended consequences.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We recognize that these capabilities may not yet be widely adopted in some settings, and that successful implementation of these capabilities may vary across providers and systems. We note that we are finalizing that the Electronic Prior Authorization measure would be reported as an attestation (yes/no) measure, as opposed to the proposed numerator and denominator, which should reduce some of the initial implementation challenges. We are also finalizing that the measure would first be reportable beginning with the CY 
                        <PRTPAGE P="8920"/>
                        2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. This delayed implementation will give both providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) and payers time to implement these changes to workflows and establish integrations prior to the measure reporting being required.
                    </P>
                    <P>We believe electronic prior authorization capabilities represent an important investment that will benefit providers, patients, and other health care system entities. We note that some payers do not fall under the definition of impacted payers in this final rule. Therefore, we are finalizing the measure's exclusion criterion (excluding MIPS eligible clinicians, eligible hospitals, and CAHs that only order medical items or services [excluding drugs] requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements finalized in this final rule) because we do not want to penalize MIPS eligible clinicians, eligible hospitals, or CAHs for ordering medical items or services (excluding drugs) from payers that do not have the API functionality for reasons such as not being an impacted payer.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that they oppose measures that could negatively impact a MIPS eligible clinician's score, such as the current all-or-nothing scoring methodology used to score the MIPS Promoting Interoperability performance category. Another commenter stated their belief that the proposed rule lacks detail on how the Electronic Prior Authorization measure will be scored and tied into the broader scoring of the Medicare Promoting Interoperability Program for eligible hospitals and CAHs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that the overall scoring methodology for MIPS Promoting Interoperability performance category is not being changed with the addition of the Electronic Prior Authorization measure, nor the scoring methodology for the HIE measure itself. As discussed previously in this section, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates that the MIPS eligible clinicians is not a meaningful EHR user and warrants the MIPS eligible clinician receive a score of zero for the MIPS Promoting Interoperability performance category. While we understand that the all-or-nothing approach requires MIPS eligible clinicians to report and attest to all requirements, we note that requiring the Electronic Prior Authorization measure is in alignment with our scoring policies and methodologies. Our regulation at 42 CFR 414.1375(b) provides that, to earn a score for the MIPS Promoting Interoperability performance category, the MIPS eligible clinician must report on objectives and associated measures as specified by CMS.
                    </P>
                    <P>For additional information on overall MIPS scoring policies and MIPS Promoting Interoperability performance category scoring policies, we refer readers to our regulations at 42 CFR 414.1375 (governing the requirements for the MIPS Promoting Interoperability performance category), 42 CFR 414.1380 (governing scoring for MIPS), as well as Table 46: Scoring Methodology for the Performance Period in CY 2024 for the Promoting Interoperability performance category in the CY 2024 PFS final rule (88 FR 52587). For information on the overall scoring methodology currently used to calculate MIPS final scores, we refer readers to the MIPS Final Score Methodology section in the CY 2024 PFS final rule (88 FR 52591).</P>
                    <P>To be considered a meaningful EHR user, fulfill the minimum reporting requirements, and avoid a downward payment adjustment, the Medicare Promoting Interoperability Program requires that eligible hospitals and CAHs meet, by reporting on or attesting to, all objectives and measures selected by CMS. Failure to meet the minimum reporting requirements results in failure of the Medicare Promoting Interoperability Program, subjecting the eligible hospital or CAH to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).</P>
                    <HD SOURCE="HD3">b. Prior Authorization API Functionality</HD>
                    <P>In the proposed rule (87 FR 76313), we proposed that a prior authorization request must be made using the Prior Authorization API to satisfy the Electronic Prior Authorization measure. The Prior Authorization API functionality is outlined in further detail in section II.D.2. of this final rule. We proposed that prior authorization requests that are made using fax, mail, or portal would be included in the denominator of the measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case any such prior authorization request would be excluded from the denominator. Instances where a payer offering the Prior Authorization API specifically requests a mailed or faxed prior authorization would be included in the denominator. Prior authorization requests that are made using fax, mail, or portal would not be included in the numerator of the measure because these methods would not incentivize using the standards-based API functionality as intended by the measure. Prior authorizations for any and all drugs would be excluded from both the numerator and denominator of the measure. (For a more detailed discussion of the exclusion of drugs, see section I.C. of this final rule.)</P>
                    <P>We proposed that only prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT would be included in the numerator. Using the API to query documentation requirements alone, and not to request the prior authorization, would not count in the numerator or denominator.</P>
                    <P>To satisfy the Electronic Prior Authorization measure, the health care provider uses data from their CEHRT (such as patient demographics and medical information) to justify the prior authorization request. The Prior Authorization API then automates the HIPAA-compliant prior authorization request. Additional information not contained in CEHRT may also be required for submission.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization and until the Prior Authorization API workflow is established. A commenter urged CMS to evaluate whether sufficient implementation guidance exists to support automating data retrieval before moving to require the Electronic Prior Authorization measure in future years. Some commenters noted that CMS must ensure that the desired standards outlined in the Electronic Prior Authorization measure specification are achievable. Another commenter recommended that CMS make all IGs required for payers so the burden is not placed on providers to figure out something that will be incredibly difficult and resource-intensive to do. Another commenter recommended that CMS or ONC should issue an IG to ensure there is standardization of implementation across payers. The commenter stated that IGs could reduce payer variability in the creation of the Prior Authorization API. Another commenter sought clarification on how it will be feasible for CEHRT to implement an API-based prior authorization functionality to support performance measurement if payers are not required to adhere to standardized IGs. The commenter stated that for this to occur seamlessly CEHRT standards 
                        <PRTPAGE P="8921"/>
                        would need to be updated appropriately.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for sharing their recommendations. We are working with HL7, the HL7 FHIR accelerator workgroups, and interested parties within the standards development industry to move the IGs towards greater maturity by defining technical specifications, participating in and convening testing events for them, and developing and maintaining the technical specifications. Electronic prior authorization using a FHIR API has been implemented and is in production, proving sufficient implementation guidance exists. We agree that IGs help to ensure standardization of implementation across the industry. In section II.G. of this final rule, we outline the required standards and technical specifications necessary to build the Prior Authorization API and to ensure that implementation is consistent across all impacted payers and providers to avoid unnecessary duplication of efforts. We have also recommended certain IGs to help providers and payers meet that requirement. These IGs are developed using a consensus process involving many members of the payer and provider communities. They aid in the implementation process of the APIs. We anticipate that payers will use the recommended IGs so that most, if not all, providers benefit from a standardized approach to accessing patient data with all payers with whom they contract. Our approach in the proposed rule of recommending, but not requiring, the specific IGs for each API implementation was to provide directional guidance with flexibility to the industry without locking implementers into the versions available at the time of the proposed rule. As industry moves forward with implementation of these policies and use of these standards, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS explain that the electronic prior authorization workflow does not necessarily need to be completed by the provider and that such workflows do not necessarily need to be included in CEHRT. The commenter recommended that CMS emphasize that only using data from CEHRT as part of the process for requesting prior authorization via a payer's Prior Authorization API is sufficient to meet the Electronic Prior Authorization measure. Another commenter suggested that CMS should consider not limiting the Electronic Prior Authorization measure to only data relevant to a prior authorization that is obtained from an EHR as relevant prior authorization data may not be limited to the provider's EHR alone. A commenter stated that certain health insurance data, clinical data, and other administrative data subject to follow-up requests or initial submissions may exist in non-EHR systems in use. The commenter stated that this further underscores the premise that any health IT developer wishing its health IT to be certified must support all USCDI in its health IT. The commenter stated that USCDI as a driver to enable standards-based exchange is increasingly less relevant and, instead, the various IGs would indicate what participating systems should support. A commenter requested clarification on the expectations for incorporating such workflows into the Medicare Promoting Interoperability Program. The commenter sought clarification on whether eligible hospitals are expected to begin to share prior authorization information via the integrations with HINs to meet the bi-directional HIE measure. Multiple commenters encouraged the use of HIEs to connect impacted payers and providers to facilitate electronic prior authorization. A commenter stated that HIEs could provide support for continuing to connect providers and payers, including for the purposes of prior authorization. Another commenter recommended that CMS should include an optional, alternative measure that allows MIPS eligible clinicians, eligible hospitals, and CAHs to claim a Promoting Interoperability credit by attesting to using a HIE/HIN to request a prior authorization. Another commenter recommended that CMS create a health IT activity as part of the HIE Objective for mapping to a Prior Authorization API that is measured by the transmission of at least one prior authorization through the Prior Authorization API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose, and are not finalizing, details of a specific workflow, or by whom, that must be completed to report the Electronic Prior Authorization measure beyond specifying that data from CEHRT must be used for the transaction with a Prior Authorization API. CMS recognizes that, under the Electronic Prior Authorization measure that we are finalizing in this rule, MIPS eligible clinicians, eligible hospitals, and CAHs may utilize different workflows to submit an electronic prior authorization request. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955-AA06). The description for this proposed rulemaking notes that this rule aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals.
                        <SU>165</SU>
                        <FTREF/>
                         We plan to continue to explore how potential future updates to the ONC Health IT Certification Program can support our policies and will address any updates to our requirements related to these future updates to the ONC Health IT Certification Program criteria if finalized, in future rulemaking. In reference to the USCDI, we note that health IT modules may be certified to only one or a few certification criteria that do not reference the USCDI standard, and therefore are not all required to support USCDI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>With regard to workflows, there is no requirement under the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program that a specific individual person must request prior authorization electronically via the Prior Authorization API to meet requirements of the Electronic Prior Authorization measure. Instead, it can be someone who legally can enter information into the medical record in accordance with applicable laws and professional guidelines. Regarding the measure's specifications, we emphasize that data must come from the CEHRT, as use of CEHRT is a required element of both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. However, additional data outside of CEHRT may also be used in addition to support the interaction with a Prior Authorization API.</P>
                    <P>
                        Regarding the USCDI, we note that this standard is referenced in many of the IGs recommended for these use cases, however, the relative utility, in the abstract, of USCDI as a standard adopted for use in certified health IT and cross referenced in certain ONC Health IT Certification Program criteria is outside the scope of this final rule. We also note that we did not propose and are not finalizing a requirement under the MIPS Promoting 
                        <PRTPAGE P="8922"/>
                        Interoperability performance category or the Medicare Promoting Interoperability Program to share prior authorization information via the integrations with HINs to meet the Bi-Directional HIE measure. Additionally, we thank commenters for their recommendations on additional measures to promote electronic prior authorization. CMS reiterates that to meet the requirements of the Electronic Prior Authorization measure, the electronic prior authorization must use a Prior Authorization API as finalized in this rule. CMS agrees that using HIEs and other HINs could help to facilitate sharing of prior authorization information. Nothing in the Electronic Prior Authorization measures we are finalizing would restrict using such networks as long as the payer's Prior Authorization API is used for the electronic prior authorization.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification on whether a provider must implement capabilities to connect to all parts of the Prior Authorization API for full automation of the electronic prior authorization processing in order to claim numerator credit. Another commenter questioned whether a provider meets the numerator criteria if they use the Prior Authorization API that does not meet all the capabilities outlined in the recommended HL7 Da Vinci CRD, DTR, and PAS IGs. Another commenter requested clarification regarding whether a MIPS eligible clinician using the Prior Authorization API to submit a prior authorization request is not required to use all capabilities (that is, CRD, DTR, and PAS) in order to meet the numerator qualification, but rather that, at a minimum, the PAS IG request is used.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback and note that we are finalizing this measure with modification to no longer require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the measure. Instead, we are finalizing this measure to require MIPS eligible clinicians, eligible hospitals, and CAHs to attest a “yes” or “no” response for the measure or claim an applicable exclusion. In order to attest “yes,” for at least one medical item or service (excluding drugs) and, for eligible hospitals and CAHs, for one hospital discharge ordered during the performance period or EHR reporting period, a prior authorization request must be submitted to a payer using a Prior Authorization API. We note that to report a “yes,” the action of the measure must occur during the selected performance period 
                        <SU>166</SU>
                        <FTREF/>
                         or EHR reporting period,
                        <SU>167</SU>
                        <FTREF/>
                         as per the measure specification. The Prior Authorization API is discussed in more detail in section II.D. of this final rule, and we note that the submission of the prior authorization request itself is described through the recommended PAS IG.
                    </P>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             
                            <E T="03">See</E>
                             42 CFR 414.1320.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             
                            <E T="03">See</E>
                             42 CFR 495.40(b)(2)(i).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters stated that certain EHR systems are more sophisticated than others and could track Prior Authorization API activity, while other hospitals and providers lack this technology. A commenter sought clarification on how a provider can use their EHR to identify situations where the prior authorization cannot be requested via a payer's Prior Authorization API for the purposes of performance measurement. A commenter stated that some provider systems do not support one or more payer APIs due to slight differences in structure, interpretation, or both, which could result in the provider being penalized due to an EHR system's lack of capability and not the provider's lack of desire to use the Prior Authorization API. A commenter noted that the Electronic Prior Authorization measure would be counterproductive to ONC's strategy of reducing burden related to using health IT and EHRs and that there should be near-zero reporting burden. Multiple commenters noted that there will be technical and financial challenges with adopting an electronic prior authorization process. Some commenters recommended that CMS should provide financial and technical assistance/training to providers to adopt and implement the technology requirements. The commenter noted that some provider types, such as physical therapists, are ineligible to participate in the Medicare and Medicaid EHR Incentive Programs and have received little guidance on using EHR systems. A commenter stated that CMS should acknowledge the significant financial and administrative risk providers face when purchasing EHR systems in the context of MIPS. A commenter noted that many health IT vendors currently charge separately for electronic prior authorization functionality and the cost associated with purchasing these functionalities has been a substantial barrier to adoption for many small and independent practices, as well as rural hospitals. Some commenters noted the financial burden associated with using APIs and that practices must first be able to affordably adopt this technology before a new requirement is established for its use.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge there will be variability in EHR technology capabilities to track Prior Authorization API activity. As noted previously, for this reason and to reduce reporting burden, we are finalizing the Electronic Prior Authorization measure as an attestation (yes/no) measure. As noted, ONC has sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, has been updated to include an entry for a proposed rule from ONC (RIN 0955-AA06) that includes proposals for the expanded use of certified APIs for electronic prior authorization.
                        <SU>168</SU>
                        <FTREF/>
                         We will monitor these developments in order to inform updates to the Electronic Prior Authorization measure in the future, for instance, requiring reporting of a numerator and denominator.
                    </P>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>While we acknowledge there may be costs associated with implementing functionality needed to interact with a payer's Prior Authorization API, as well as add-on costs charged by health IT vendors for adding these features, we believe that the benefits of the technology outweigh the costs. We also remind readers that this attestation (yes/no) measure would not be included under the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category until the CY 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. We believe extending the inclusion of the Electronic Prior Authorization measure to the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs will allow participants in these programs to work with health IT vendors to adopt and implement functionality that can facilitate the actions needed to satisfy the Electronic Prior Authorization measure.</P>
                    <P>
                        As far as technical assistance, CMS does host CMS and HL7 FHIR Connectathons, which are free for interested parties to attend, as well as provides educational webinars with overviews of the technical requirements 
                        <PRTPAGE P="8923"/>
                        in the CMS Interoperability and Patient Access final rule and proposed requirements in the CMS Interoperability and Prior Authorization proposed rule. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings. CMS believes that using the EHR systems, and training for staff using them, is up to each practice or hospital system to ensure occurs.
                    </P>
                    <P>CMS also is aware that the initial incentive programs (that is, the Medicare and Medicaid EHR Incentive Programs) supported EHR adoption for only certain provider types and the challenges that brings for certain provider types that were not originally eligible for this funding. CMS continues to evaluate ways to support providers that may lag in health IT adoption.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS establish requirements for impacted payers to publish their API endpoints for the Prior Authorization API or provide information on where to find the APIs and make information concerning how to connect to them conspicuously available for third-party app developers and for providers through their public websites similar to what is asked of certified health IT developers of API functions as a part of their basis of CEHRT under 45 CFR 170.315(g)(10).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand that a directory of impacted payers' digital endpoints would be highly beneficial to facilitate the Prior Authorization API. Without such a directory, payers would need to discover other payers' endpoints one by one, and each payer would have to maintain a list of payers with whom they have previously connected. Therefore, we are committing to exploring an NDH that contains payers' digital endpoints before the 2027 compliance dates for the Prior Authorization API, which could allow providers to easily access those APIs and thereby facilitate electronic prior authorization, as discussed in this final rule. Further details about the NDH structure, requirements, and timing will be released if and when they become available.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter discussed the X12 standards and expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Multiple commenters recommended that CMS should include the usage of the X12 278 standard in the numerator of the proposed measures. A commenter noted organizations that have standardized usage of the X12 standard may find this effective and efficient. The commenter stated that requiring these groups to transition to the Prior Authorization API to meet the measure requirements would be disruptive and burdensome. Another commenter recommended CMS use a single standard if CMS would like to incorporate the Electronic Prior Authorization measure. A commenter also recommended that CMS provide guidance on the role of HIPAA administrative transaction standards.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their feedback; however, we do not agree that the X12 278 standard is appropriate for the numerator of the proposed Electronic Prior Authorization measure because of its persistent and historically low utilization. While the CAQH efficiency index report is more reflective of payer and vendor uptake of the HIPAA standards, it does include some provider information.
                        <SU>169</SU>
                        <FTREF/>
                         In the last four reporting years, the utilization of the X12 278 transaction has not exceeded 21 percent. Comments from reporting submitters (for the CAQH Index) indicate that providers do not use the X12 278 because it does not include the data elements they need for complete processing, and many payers are still not supporting it. Thus, to consider using that standard as the numerator, knowing the utilization rates are low, would not seem appropriate. We believe the benefit of moving towards a standardized electronic prior authorization process that leverages FHIR outweighs the initial implementation cost and burden of the transition. We will continue coordinating with colleagues across CMS and other Federal agencies on all ways that that HIPAA administrative transaction standards could impact our policies. We also note that we are finalizing a modification to our proposal to no longer require reporting of a numerator and denominator for this measure, as discussed in more detail throughout this section.
                    </P>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             Coalition for Affordable Quality Healthcare (2022). The CAQH Index Report. Retrieved from 
                            <E T="03">https://https://www.caqh.org/insights/caqh-index-report.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Measure Exclusions</HD>
                    <P>In the proposed rule (87 FR 76314), we proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period or EHR reporting period could claim an exclusion for the Electronic Prior Authorization measure. We also proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that only order medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule (that is, payers not subject to this regulation or impacted payers that are non-compliant with the Prior Authorization API requirements outlined in section II.D.2. of this final rule), during the applicable performance period/MIPS payment year or EHR reporting period, could claim an exclusion for the Electronic Prior Authorization measure. As an alternative to this proposal, we considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small number of prior authorizations, such as five prior authorizations during the performance period/EHR reporting period, should also be able to claim the exclusion. We sought public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion. Given the previously discussed limitations of the current prior authorization process, we believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the payers they request prior authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of prior authorization requests, other than zero, would be a reasonable threshold for claiming an exclusion for the Electronic Prior Authorization measure.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters stated that if a payer insists on faxing or other means of communication, CMS should consider treating this scenario as the basis for exclusion from the Electronic Prior Authorization measure versus still having authorizations impacted by such a requirement of a payer included in the denominator. A commenter stated that some practitioners do not have enough prior authorization requests or the necessary technology to support electronic prior authorization, and suggested the exclusion should be based on not only quantity but also on technical capability of those who do not submit a high volume of prior authorization requests. The commenter encouraged CMS to consider alternative exclusion criteria, such as the technical 
                        <PRTPAGE P="8924"/>
                        capability of those who do not submit a high volume of prior authorization requests. The commenter continued by stating that CMS should not penalize providers for failing to use EHRs for this purpose of electronic prior authorization if they either do not have enough requests or if the technology they use does not support this capability.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' recommendations and feedback that some providers may not have enough prior authorization requests or the necessary technology to support electronic prior authorization. We believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the impacted payers they request prior authorization from) would benefit from using the electronic prior authorization process described in this final rule. We also note that the modified version of the Electronic Prior Authorization measure being finalized in this rule only requires reporting of “at least one” medical item or service (excluding drugs) ordered during the performance period/MIPS payment year or EHR reporting period. We believe this is achievable for all MIPS eligible clinicians, eligible hospitals, and CAHs who make any prior authorization requests in a given year. For those who do not have any prior authorization requests, we are finalizing our exclusion as proposed. MIPS eligible clinicians, eligible hospitals, and CAHs who do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period/MIPS payment year or EHR reporting period would be able to report that they qualify for the exclusion for the Electronic Prior Authorization measure.
                    </P>
                    <P>We acknowledge that EHR technology may not consistently support interactions with the Prior Authorization APIs at this time, and as discussed in further detail elsewhere in this section, we will continue to work with ONC on potential ONC Health IT Certification Program criteria that would support the Electronic Prior Authorization measure. For this reason, we are finalizing this measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and for the Medicare Promoting Interoperability Program beginning with the CY 2027 EHR reporting period.</P>
                    <HD SOURCE="HD3">d. Office of the National Coordinator for Health Information Technology Health IT Certification Program</HD>
                    <P>
                        As described previously, ONC previously sought comment through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022, issue of the 
                        <E T="04">Federal Register</E>
                        , on how updates to the ONC Health IT Certification Program could support electronic prior authorization. Since then, the Unified Agenda has been updated to include a proposed rule from ONC (RIN 0955-AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals.
                        <SU>170</SU>
                        <FTREF/>
                         We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to future updates to the ONC Health IT Certification Program, if finalized, in future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">e. Other Considerations</HD>
                    <P>We invited public comment on considerations and alternatives related to the Electronic Prior Authorization measure. For example, we sought comment on the proposed numerator and denominator of the Electronic Prior Authorization measure or any changes to the specifications that would reduce the implementation burden for both impacted providers (MIPS eligible clinicians, eligible hospitals, and CAHs) and health IT developers. We also sought comment on challenges that MIPS eligible clinicians, eligible hospitals, and CAHs might face in identifying those payers that have the Prior Authorization API technology to accurately include eligible prior authorization requests in the denominator. Additionally, we sought comment on challenges MIPS eligible clinicians, eligible hospitals, and CAHs could face in performing the actions included in the Electronic Prior Authorization measure specifications if certification criteria are not available in the ONC Health IT Certification Program at the time MIPS eligible clinicians, eligible hospitals, and CAHs are required to report the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category.</P>
                    <P>We received many comments in response to our request for comment. We thank commenters for their feedback as we consider any future rulemaking, including collaboration with ONC as appropriate.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters opposed the proposed Electronic Prior Authorization measure because of the lack of health IT certification criteria to ensure EHRs communicate with payers through Prior Authorization API. Multiple commenters expressed concern about the inclusion of the Electronic Prior Authorization measure due to possible technical challenges and the lack of health IT that has the capacity to support electronic prior authorization. Multiple commenters encouraged CMS to focus on ensuring that the proposed APIs are implemented and supported by CEHRT to make sure they are successfully implemented within the provider's workflow rather than developing a measure related to electronic prior authorization.
                    </P>
                    <P>
                        Several commenters noted that ONC has not established health IT certification criteria to support electronic prior authorization in such technologies. Multiple commenters suggested various alternative timeframes for CMS to consider. A commenter recommended that CMS require payers to make the Prior Authorization API available to providers no later than 12 months following the publication of this final rule. Another commenter suggested a compliance date 12 months after the implementation of the Prior Authorization API or 36 months following publication of this final rule, whichever is later. Another commenter requested that CMS consider reopening the comment period for this rule following the publication of the HTI-1 proposed rule (88 FR 23746). The commenter stated that CMS should give industry 24 months from the reopening of the comment period to create specifications, perform development, complete certification testing, and execute client deployments. Another commenter recommended that CMS suspend the proposed Electronic Prior Authorization measure until payers implement and maintain the Prior Authorization API as specified in this rule and the Prior Authorization API is in effect for at least 3 years. Multiple commenters were concerned that providers will not be guaranteed access to the Prior Authorization API if health IT developers are not required to incorporate the functionality into CEHRT and therefore should not be held 
                        <PRTPAGE P="8925"/>
                        accountable for using the Prior Authorization API nor reporting on the proposed Electronic Prior Authorization measure. A commenter recommended that CMS and ONC work in collaboration to leverage technologies, such as electronic prior authorization tools. Another commenter urged CMS to work with ONC to establish ONC Health IT Certification Program criteria to require providers and EHR vendors to adopt the IGs associated with electronic prior authorization. Commenters stated that it is unreasonable to measure utilization by MIPS eligible clinicians, eligible hospitals, and CAHs of electronic prior authorization processes for incentive payments until the ONC Health IT Certification Program requires CEHRT to include the functionality necessary for health IT systems to communicate through a Prior Authorization API. Another commenter stated that CMS should postpone implementation of the Electronic Prior Authorization measure until both the ONC Health IT Certification Program and HIPAA attachment standards are updated. Another commenter stated that the proposed Electronic Prior Authorization measure would subject MIPS eligible clinicians, eligible hospitals, and CAHs to be reliant upon untested technology and tie their performance to such technology. A commenter emphasized the importance of industry adoption and noted that the API will have minimal value if EHR vendors do not build the necessary connections to allow clinicians to access it and if clinicians are not incentivized to adopt. To mitigate this, the commenter recommended that CMS require EHR vendors to provide bi-directional patient data access via an API so payers can better leverage digital patient information and automate prior authorization requests. Another commenter recommended that CMS ensure that the proposed Electronic Prior Authorization measure is supported by technology used by all of the impacted users. Several commenters stated that providers should not be subject to punitive action if they do not implement the Prior Authorization API requirements and should not be evaluated on electronic prior authorization utilization for payment purposes until EHRs are required to provide this functionality by the ONC Health IT Certification Program.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the comments received on this request for comments. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC (RIN 0955-AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization.
                        <SU>171</SU>
                        <FTREF/>
                         We will work with ONC to ensure that any future updates to the ONC Health IT Certification Program around electronic prior authorization will improve health care providers' capabilities to interact with the Prior Authorization APIs established by impacted payers, as well as further support health care providers' ability to complete the action specified in the Electronic Prior Authorization measure we are finalizing. We will provide further guidance in future rulemaking about how any updates made by ONC to the ONC Health IT Certification program related to electronic prior authorization relate to the requirements of the Medicare Promoting Interoperability Program and Promoting Interoperability performance category of MIPS. We note that CMS does not have authority to regulate EHR vendors directly; however, we collaborate with ONC regarding certification criteria for health IT that are included in the voluntary ONC Health IT Certification Program and referenced in CMS program requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>In the interim, we note that MIPS eligible clinicians, eligible hospitals, and CAHs are required to use CEHRT for the measure as a means to capture clinical information as structured data and to use such structured data for the prior authorization. This function of gathering structured data from CEHRTs is achievable today without additional CEHRT criteria. The request for prior authorization through the Prior Authorization API could be accomplished through the use of additional technology to complement CEHRT depending on implementation preference. We note that MIPS eligible clinicians, eligible hospitals, and CAHs can report on the measure, saying “yes” they submitted a prior authorization request electronically using the Prior Authorization API with data from CEHRT, without needing additional certification criterion in the ONC Health IT Certification Program.</P>
                    <P>We also note that in December 2022, HHS proposed to adopt a standard for attachments in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). That proposed rule has not yet been finalized. At this time there are no operating rule requirements applicable to the APIs required for use in this final rule, or to the HIPAA X12 278 transaction standard.</P>
                    <P>We appreciate commenters' recommendations regarding implementation timelines, such as making the Prior Authorization API available to providers no later than 12 months or 36 months following the publication of this final rule. We note that, after consideration of comments received and discussed in more detail elsewhere in the rule, we are finalizing our proposal with the modification to have MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period. We also acknowledge that a commenter recommended suspending the Electronic Prior Authorization measure until payers implement the Prior Authorization API as specified in this rule and use it for some time period. However, we believe finalization of this Electronic Prior Authorization measure encourages all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to drive widespread adoption, thus reaping the benefits of burden reduction through electronic prior authorization processes. The Prior Authorization API needs parties on both ends of a request to be using the API in order for the API to be beneficial to everyone involved.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that ONC conduct oversight of CEHRT products to determine if the products do or do not successfully support electronic prior authorization, and then publicize CEHRT products that fail ONC review on the Certified Health IT Product List (CHPL) so providers can avoid products that will not support the new electronic prior authorization requirements. The commenter recommended that ONC work with professional associations to educate providers about their oversight and reporting process.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         There is not a dedicated certification criterion related to electronic prior authorization in the ONC Health IT Certification Program at this time. However, as noted previously, ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC 
                        <PRTPAGE P="8926"/>
                        (RIN 0955-AA06), which describes planned proposals for the expanded use of certified APIs for electronic prior authorization.
                        <SU>172</SU>
                        <FTREF/>
                         We note that the Electronic Prior Authorization measure requires using data from CEHRT, and the Prior Authorization API can be implemented without regard to any changes ONC may propose for the ONC Health IT Certification Program.
                    </P>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>
                        While ONC oversight and enforcement authority is beyond the scope of this final rule, we note that health IT products certified to all certification criteria are subject to oversight mechanisms within the ONC Health IT Certification Program. For more information about the oversight elements within the ONC Health IT Certification Program, readers should visit the ONC website at 
                        <E T="03">https://www.healthit.gov/topic/certification-ehrs/oversight-and-surveillance.</E>
                         Regarding the CHPL (
                        <E T="03">https://chpl.healthit.gov/</E>
                        ), we note this resource includes listings of those health IT products that have successfully certified to health IT certification criteria under the Certification Program.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS and ONC outline a roadmap for electronic prior authorization adoption that leverages the ONC Health IT Certification Program. A commenter recommended that the roadmap should include details from the ONC Cures Act final rule (85 FR 25642) and these requirements. Another commenter stated that an established path to electronic prior authorization will avoid delays and confusion.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' feedback. CMS will consider developing a roadmap for electronic prior authorization adoption in collaboration with ONC. We will collaborate with ONC to incorporate any future policies for the ONC Health IT Certification Program as part of a comprehensive approach to ensuring electronic prior authorization is conducted in a standardized fashion across parties.
                    </P>
                    <HD SOURCE="HD3">3. Final Action</HD>
                    <P>After consideration of the comments received and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:</P>
                    <P>• The “Electronic Prior Authorization” measure will be reported as an attestation (yes/no) measure, instead of reporting a numerator and denominator, regarding whether the MIPS eligible clinician, eligible hospital, or CAH submitted at least one prior authorization request electronically via a Prior Authorization API using data from CEHRT during the performance period/EHR reporting period, as further specified below.</P>
                    <P>• MIPS eligible clinicians will report the “Electronic Prior Authorization” measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs participating under the Medicare Promoting Interoperability Program will report the measure beginning with the CY 2027 EHR reporting period.</P>
                    <P>See further discussion below for exact details of the final requirements for MIPS eligible clinicians, eligible hospitals, and CAHs.</P>
                    <P>We are finalizing the following specifications for the Electronic Prior Authorization measures:</P>
                    <HD SOURCE="HD3">1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization</HD>
                    <P>
                        • 
                        <E T="03">Measure Description:</E>
                         For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>
                        • 
                        <E T="03">Reporting Requirements:</E>
                         Yes/No response.
                    </P>
                    <P>To successfully report this measure, MIPS eligible clinicians must attest “yes” to requesting prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period or (if applicable) report an exclusion.</P>
                    <P>
                        • 
                        <E T="03">Exclusion:</E>
                         Any MIPS eligible clinician who—
                    </P>
                    <P>++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or</P>
                    <P>++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule during the applicable performance period.</P>
                    <HD SOURCE="HD3">2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program—Electronic Prior Authorization</HD>
                    <P>
                        • 
                        <E T="03">Measure Description:</E>
                         For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.
                    </P>
                    <P>
                        • 
                        <E T="03">Reporting Requirements:</E>
                         Yes/No response.
                    </P>
                    <P>To meet this measure, the eligible hospital or CAH must attest “yes” to requesting a prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period or (if applicable) report an applicable exclusion.</P>
                    <P>
                        • 
                        <E T="03">Exclusions:</E>
                         Any eligible hospital or CAH that—
                    </P>
                    <P>++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the EHR reporting period.</P>
                    <P>++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule during the applicable EHR reporting period.</P>
                    <P>We intend to reevaluate the Electronic Prior Authorization measure criteria and reporting structure of this measure in future years as the Prior Authorization API becomes more widely adopted and if additional certification criteria become available for CEHRT to determine whether a numerator/denominator reporting structure would be more appropriate at that time. We would address those issues in future rulemaking.</P>
                    <P>
                        We are finalizing our proposal that the Electronic Prior Authorization measure will not be assigned points for the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians, and the CY 2027 EHR reporting period for eligible hospitals and CAHs. Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure to meet the minimum reporting 
                        <PRTPAGE P="8927"/>
                        requirements of the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS.
                    </P>
                    <P>
                        For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response on the attestation or claiming an applicable exclusion. A “no” response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR 414.1305). MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a “no” response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). We note that to report a “yes,” the action of the measure must occur during the selected performance period 
                        <SU>173</SU>
                        <FTREF/>
                         or EHR reporting period,
                        <SU>174</SU>
                        <FTREF/>
                         as per the measure specification defined below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>173</SU>
                             
                            <E T="03">See</E>
                             42 CFR 414.1320.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>174</SU>
                             
                            <E T="03">See</E>
                             42 CFR 495.40(b)(2)(i).
                        </P>
                    </FTNT>
                    <P>
                        For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act.
                        <SU>175</SU>
                        <FTREF/>
                         Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).
                    </P>
                    <FTNT>
                        <P>
                            <SU>175</SU>
                             
                            <E T="03">See</E>
                             42 CFR 495.4 and 495.24(f)(1)(i)(A).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">G. Interoperability Standards for APIs</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the API technical standards at 45 CFR 170.215, which at the time included (85 FR 25521):</P>
                    <P>• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1</P>
                    <P>• HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1</P>
                    <P>• HL7® SMART Application Launch Framework IG Release 1.0.0, including mandatory support for the “SMART Core Capabilities”</P>
                    <P>• FHIR® Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1), including mandatory support for the “group-export” “OperationDefinition”</P>
                    <P>• OpenID Connect Core 1.0, incorporating errata set 1</P>
                    <P>
                        When we finalized the requirement for conformance with the specifications at 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule, we required impacted payers to comply with all standards at 45 CFR 170.215 for each of the APIs finalized in that rule. However, we understand that the existing requirements for payers to “use API technology conformant with 45 CFR 170.215” (85 CFR 25632) for each API may introduce confusion to the compliance requirements, because not all the standards at 45 CFR 170.215 may be applicable for each specific API.
                        <SU>176</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>176</SU>
                             
                            <E T="03">See</E>
                             42 CFR 422.119 (Access to and exchange of health data and plan information), 431.60 (Beneficiary access to and exchange of data), and 457.730 (Beneficiary access to exchange of data) and 45 CFR 156.221 (Access to and exchange of health data and plan information).
                        </P>
                    </FTNT>
                    <P>Accordingly, to provide clarity, in the CMS Interoperability and Prior Authorization proposed rule, we outlined modifications to be more specific regarding which standards at 45 CFR 170.215 are applicable to each API (87 FR 76314-21). Specifically, instead of the existing requirements to use “API technology conformant with 45 CFR 170.215,” we proposed that each standard at 45 CFR 170.215 would apply to a given set of APIs. The specific CFR citations were listed in Table 8 of the proposed rule (87 FR 76318). We are now finalizing those requirements, with modifications to some of the specific API requirements. We are finalizing that impacted payers will only be required to use those specifications at 45 CFR 170.215 that are listed in Table H3 as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. We are also finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs. Finally, we are reiterating our recommendations to use the IGs listed in Table H3. We discuss these policies in detail elsewhere in the final rule.</P>
                    <HD SOURCE="HD3">2. Modifications to Required Standards for APIs</HD>
                    <P>We proposed specific standards at 45 CFR 170.215 that would apply to each API. In the proposed rule, we listed the standards applicable to each API in Table 10 (87 FR 76320). Since the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has published the HTI-1 final rule which reorganized the structure of 45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification (89 FR 1283). We note that the HTI-1 final rule adopted updated versions of several standards at 45 CFR 170.215, which now includes:</P>
                    <P>• Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR);</P>
                    <P>• HL7 FHIR US Core IG Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i);</P>
                    <P>• HL7 FHIR US Core IG STU 6.1.0 at 45 CFR 170.215(b)(1)(ii) (US Core IG),</P>
                    <P>• HL7 SMART Application Launch Framework IG Release 1.0.0, which expires on January 1, 2026, at 45 CFR 170.215(c)(1);</P>
                    <P>• HL7 SMART App Launch IG Release 2.0.0 at 45 CFR 170.215(c)(2) (SMART App Launch IG);</P>
                    <P>• FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1) at 45 CFR 170.215(d)(1) (Bulk Data Access IG); and</P>
                    <P>• OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core).</P>
                    <P>
                        We refer readers to the HTI-1 proposed and final rule for additional information (FR 1284 through 1295). The specific standards at 45 CFR 170.215 that we identified in our proposed rule were restructured by HTI-1 and moved to new locations at 45 CFR 170.215. In addition, in several cases ONC adopted new versions of the same standards proposed in the CMS Interoperability and Prior Authorization proposed rule. Specifically, ONC finalized US Core IG STU 6.1.0 (at 45 
                        <PRTPAGE P="8928"/>
                        CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(c)(1)) to indicate when a version of a standard may no longer be used for the ONC Health IT Certification Program. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to our API compliance dates.
                    </P>
                    <P>We are finalizing our proposals to identify specific required standards at 45 CFR 170.215 that are applicable to each of the APIs, with modifications. The finalized requirements include any additional mandatory support requirements listed, such as for both the SMART App Launch IG at 45 CFR 170.215(c) and Bulk Data Access IG at 45 CFR 170.215(d). We are cross-referencing the new locations for these standards at 45 CFR 170.215 finalized by ONC in the HTI-1 final rule. Table H3 lists the required versions of each standard and their citation. Throughout this preamble we refer to the current structure of 45 CFR 170.215 as updated by the HTI-1 final rule.</P>
                    <P>For the Patient Access API, we are finalizing the required standards as proposed with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Provider Directory API, we are finalizing our proposal with modifications to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i), and to remove the SMART App Launch IG at 45 CFR 170.215(c)(1) and OpenID Connect Core at 45 CFR 170.215(e), which were erroneously included in the proposed rule. We refer readers to the footnote in Table H3 for additional information. For the Provider Access API, we are finalizing our proposal with the modification to not require OpenID Connect Core at 45 CFR 170.215(e) and with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Payer-to-Payer API, we are finalizing our proposal with modifications to not require the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e), and to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i). For the Prior Authorization API, we are finalizing our proposal with modifications to not require OpenID Connect Core at 45 CFR 170.215(e) and to incorporate expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). Payers will be required to comply with the applicable specifications that we have identified for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs as listed in Table H3. The exact regulation text for each API will vary depending on which standards apply to that API. These updates particularize the specifications at 45 CFR 170.215 that are required for each API. We received comments on these proposals and discuss details of the modifications.</P>
                    <HD SOURCE="HD3">a. HL7 FHIR and Technical Readiness</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposal to specify technical standards for each API and recommended that CMS finalize the proposal. A commenter expressed appreciation for CMS's efforts to explain the technical requirements for each API and agreed with the proposal to add more specific language regarding which standards apply to which API.
                    </P>
                    <P>Multiple commenters also supported CMS's proposal to require payers to use the FHIR standard to facilitate information exchange and promote interoperability. Multiple commenters stated that FHIR APIs help connect patients, providers, and payers to the correct information. A commenter stated that FHIR-based standards maximize the chance for innovation and the proposed revision provides technical clarity to payers. Another commenter stated that utilizing the FHIR standard continues to advance the use of transparent, widely available standards and helps to facilitate electronic information exchange, while another stated that the FHIR-based IGs support the provider team's workflow and enable them to better understand patient-specific benefits.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters support for using the FHIR standard and FHIR APIs to improve information exchange and agree with the commenters' assessments that these will advance interoperability.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern about mandating the FHIR standard. Multiple commenters expressed concern regarding the maturity of the proposed standards, specifications, and recommended IGs. Multiple commenters stated that it would be inadvisable to specify technical requirements at this time given that the technical standards and IGs have not fully matured. Multiple commenters recommended that CMS, along with ONC, take steps to adequately and inclusively develop technical standards and relevant IGs to full maturity as a baseline of industry consistency, ensuring standards are tested and transparently evaluated prior to mandated adoption. Another commenter encouraged CMS to maintain flexibility in the agency's ongoing data exchange activities to ensure the success of interoperability programs. Another commenter urged CMS to ensure careful consideration of what technical standards to require in the future. Another commenter suggested that requiring all entities to use the FHIR standard may be burdensome. The commenter stated that CMS has not proposed any alternatives and that adoption of the FHIR standard may not be feasible for small entities and asked questions such as what will happen if small businesses are not able to convert to FHIR.
                    </P>
                    <P>A commenter cautioned CMS not to view the FHIR standard as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as currently proposed, the Patient Access API would experience challenges if the FHIR standard failed to reach widespread adoption and maturity. A commenter stated that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption. The commenter stated that using the FHIR standard, agnostic of a particular IG, will give industry stakeholders greater flexibility to pilot different approaches and build consensus without the risk of distortions that could result from mandatory adoption of immature specifications.</P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for providing their thoughts regarding the FHIR standard. However, we disagree that FHIR is not mature. The primary components of the FHIR standard are mature, as are the standards we are requiring in this rule, such as the US Core IG. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, but we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. The FHIR standard will help move the health care industry toward a more interoperable state, and we believe that it supports transmission of health data in a standard, structured, but flexible format as FHIR specifications continue to advance and mature. HHS has already adopted standards for FHIR APIs at 45 
                        <PRTPAGE P="8929"/>
                        CFR 170.215, as finalized in the ONC Cures Act final rule, and therefore we did not propose any alternatives (85 FR 25521). We disagree that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption as they have already been successfully implemented and are being used today. Since 2021 impacted payers have been required to implement and maintain a standards-based Patient Access API that uses FHIR and other technical standards at 45 CFR 170.215, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). We are delaying the compliance date for policies that require API enhancement or development to 2027, which will allow additional time for the recommended FHIR IGs to be refined to support the policies in this final rule. We believe the adoption of the FHIR standard is feasible for all the APIs finalized in this rule, especially with the additional implementation time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters appreciated CMS's efforts to move industry towards interoperability and expressed support for CMS's proposals to promote electronic data exchange among patients, providers, and payers via APIs leveraging technical standards and IGs. Multiple commenters supported using FHIR-based standards to facilitate data transport across the industry and that FHIR-based exchange is technically feasible for both payers and providers to adopt and implement. A commenter stated that the FHIR standard and IGs promote a level of consistency in terms of format, structure, and vocabulary, as well as allow for a variety of interoperability paradigms that best suit the interaction requirements between providers, payers, and patients. A commenter supported using USCDI data classes and data elements in addition to claims and encounter data when exchanging patient information.
                    </P>
                    <P>Multiple commenters expressed support for CMS's proposals to use standards-based APIs and stated that the industry-wide adoption of uniform standards will help enhance interoperability and minimize complexity. Multiple commenters stated that having an established technical infrastructure to support the development and adoption of the new APIs outlined in this rule is crucial to prevent added administration burden, complexity, and variability in implementation.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenters' assessments and thank them for their support of our policies.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter requested that CMS define a more prescriptive designated data set for claims and encounter data akin to USCDI. The commenter continued by stating that CMS should explicitly call out the Common Payer Consumer Data Set (CPCDS), which would ensure a more uniform implementation and ensure that patients, providers, and payers can use those capabilities in a way that the rule intended. Another commenter suggested a realignment of the purpose and use of USCDI as a library of data types, classes, and specifications from which interoperability requirements can be drawn.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While altering the design and structure of the USCDI are out of scope for this rule, we will continue to work with ONC to expand and build upon the USCDI. For instance, we have worked with ONC on the USCDI+ initiative, which aims to harmonize data sets that extend beyond the USCDI for additional use cases. While USCDI is one category of data required to be exchanged via the APIs, we understand that the USCDI is limited in scope and that additional data and standards will be necessary to implement these APIs. For instance, the recommended HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) (87 FR 76316), which was itself informed by and includes mappings to CPCDS.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that the implementation of the APIs is contingent on compliant technical solutions being available in the marketplace. Another commenter stated that the lack of specificity in API requirements gives payers significant latitude to determine what data elements they want to include in their APIs and under what circumstances, which will not promote widespread interoperability. Another commenter stated that technical standardization and payer participation are the only ways that these proposals could be effective. The commenter stated if the responsibility is not shared across stakeholders, CMS will simply shift more burden onto providers. Another commenter stated that variance in API implementation could require providers to need significant assistance from health IT vendors to navigate these systems, which would eliminate any efficiencies CMS expected to derive from the new interoperability requirements. Another commenter noted a frequent problem with the implementation of technical processes is variation from system-to-system and interpretation differences since guidance is not universally communicated to developers who need the information. Similarly, a commenter noted that these technical API standards may require providers to hire additional staff to implement them.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The industry already has significant adoption of the FHIR standard for several use cases and there are solutions available today to FHIR-enable existing systems. Additionally, many of the IGs recommended in this rule have already been implemented by multiple implementers at some level. We anticipate more solutions will be available in the marketplace ahead of the API compliance dates in 2027. We acknowledge that using marketplace technical solutions may ease implementation. We understand that there is still a learning curve with respect to the FHIR-based standards and IGs and that entities may need to hire and train staff.
                    </P>
                    <P>We appreciate these perspectives and acknowledge that standards are what promote interoperability. The adoption of the FHIR standard and the IGs promote interoperability by enabling the secure exchange of health information across disparate systems. The FHIR APIs provide the framework for this exchange. Regarding concerns for the lack of specificity in the API requirements, we acknowledge that we are only recommending rather than requiring several IGs because they continue to evolve and are not adopted by HHS at 45 CFR 170.215. As these IGs continue to mature, we will consider proposing to require them through future rulemaking. The IGs provide the exchange of the essential data elements, such as patient demographics, clinical information, prior authorization requests, and other data to ensure the necessary information is shared between payers and providers. We acknowledge that implementation and testing will take time and welcome ongoing feedback through the programs and standards workgroups.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding the proposed technical standards and IG provisions outlined in the proposed rule. Multiple commenters noted that technical challenges around health information exchange could persist despite these proposals and that the technical standards lack the specificity and flexibility to properly support the interoperable exchange of data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We received many comments regarding our approach in the proposed rule of recommending, rather than requiring, specific IGs. We believe that this approach optimally balances the need for us to provide directional guidance without locking implementers 
                        <PRTPAGE P="8930"/>
                        into the versions of the recommended IGs that were available at the time of the proposed rule. As these IGs mature, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications, which, when ready, could be proposed through future CMS rulemaking. If we chose not to recommend specific IGs, this lack of direction would mean a more diverse set of proprietary solutions, resulting in little to no interoperability.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that there is transformative effort and overall risk in requiring the Patient Access, Provider Access, and Payer-to-Payer APIs to be implemented around the same time. A commenter noted that the attachments standard is not mature and that could hinder non-structured data exchange such as in CMS's proposals to require prior authorization documentation in the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted there is a risk in needing necessary endpoint connections and the functionality to convert documents between FHIR exchanges to be established by payers, providers, and health IT vendors for the purpose of data exchange. The commenter recommended that CMS first require the APIs and then add the exchange of attachments a few years later.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         For the Patient Access, Provider Access, and Payer-to-Payer APIs, we are requiring impacted payers to share claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. Many of the data classes and data elements are already required for the Patient Access API, which means that payers have already formatted these data and prepared their systems to share via a FHIR API. We thus believe that payers can concurrently implement the APIs in this final rule.
                    </P>
                    <P>We agree that standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. Further, as elaborated in sections II.A. and II.B. of this final rule, we agree that the burden of requiring impacted payers to make unstructured documentation available via the Patient Access and Provider Access APIs outweighs the benefits such documentation would provide. However, as discussed in section II.C., for the Payer-to-Payer API we are finalizing a requirement to exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorization requests and decisions.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters encouraged CMS to work with ONC to ensure relevant technical standards and related IGs are sufficiently mature and reflect the proper content and policies to allow seamless data transfers between payers and providers. Another commenter urged CMS to work in partnership with ONC to establish a clear pathway for the required IGs including: (1) the ability to advance IG versions outside the regulatory cycle; (2) adequate time for industry to understand and adopt new IG versions; and (3) limiting options, so as not to disrupt interoperability.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As previously mentioned in this section, the primary components of the FHIR standard are mature, as are the standards we are requiring in this rule. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. We will continue to closely coordinate our policies with ONC to ensure that they are mutually reinforcing. We are also finalizing our proposal to allow payers to use updated standards, specifications, or IGs for each API, as long as certain conditions are met, including that the updated version does not disrupt an end user's ability access the data required for that API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters shared concerns with the lack of a mandatory testing system, as well as lack of available test data, staging environments, sandboxes, and other mechanisms to help developers test their APIs. A commenter suggested CMS conduct usage validity testing of the payers' APIs throughout the development and deployment process of the APIs to track and mitigate any risks associated with missing or incorrect data. The commenter requested that CMS delay the enforcement timeline to accommodate these critical prerequisites. Likewise, another commenter recommended that CMS postpone publication of the final rule until it can require both the technical standards and IGs to prevent non-standard implementation across the industry. The commenter recommended that CMS work with the HL7 Da Vinci workgroup and ONC to ensure the APIs and associated standards are tested for complex use cases and to scale. Another commenter recommended CMS define or promote conformity to the ONC Inferno Framework. Another commenter recommended that CMS should establish a mandatory testing system like the ONC Cypress testing tool for the proposed APIs and data standards requirements.
                    </P>
                    <P>Multiple commenters noted that testing should be conducted in a variety of clinical settings, including small, independent, and rural practices, and with all end users to ensure that the technical standards and IGs are effective, adaptable, and efficient. A commenter highlighted that it is critical that any solution be fully developed and tested prior to wide-scale industry rollout and required usage to ensure the best return on the investment of industry resources. The commenter stated that this process should include careful consideration of the transactions' scalability, privacy guardrails, and ability to complete administrative tasks in a real-world setting. Other commenters recommended that CMS establish additional pilot testing programs to ensure industry readiness before the compliance dates.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that testing is an important part of the implementation process and will continue to support industry efforts to do so, including coordinating with ONC and HL7, including the DaVinci Accelerator, on such efforts. We will also continue to engage with ONC to determine whether the Inferno Framework 
                        <SU>177</SU>
                        <FTREF/>
                         could be utilized in the future. HL7's IG testing process includes privacy and security testing. Also, FAST,
                        <SU>178</SU>
                        <FTREF/>
                         which is an initiative started by ONC, identifies FHIR scalability gaps, defines solutions to address current barriers, and identifies needed infrastructure for scalable FHIR solutions. Real-world testing can only be accomplished if payers choose to pilot an implementation during the testing phase, which CMS cannot require participation in. However, we are not delaying publication of this final rule, as we understand that industry requires a firm commitment from the Federal Government to the adoption and recommendation of standards. Based on comments received, and as discussed throughout this final rule, we are delaying the compliance dates for all the policies that require API development and enhancement to 2027, which will 
                        <PRTPAGE P="8931"/>
                        allow additional time for FHIR specifications to continue to be refined and advanced to support the policies in this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>177</SU>
                             Office of the National Coordinator for Health Information Technology (n.d.). Inferno. Retrieved from 
                            <E T="03">https://inferno.healthit.gov/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>178</SU>
                             Health Level Seven International (2023, October 13). FHIR at Scale Taskforce (FAST). Retrieved from 
                            <E T="03">https://confluence.hl7.org/display/FAST.</E>
                        </P>
                    </FTNT>
                    <P>We also appreciate the multiple comments received on the importance of testing and the provision of examples, such as the ONC Cypress testing tool, which is an open-source tool used in the ONC Health IT Certification Program to ensure certified health IT accurately calculates electronic clinical quality measures (eCQMs). We will continue to collaborate with ONC and DaVinci on testing the APIs and with HL7 on communication and outreach to payers, developers, and providers.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters urged CMS to closely track and participate in the standards development process to ensure that all perspectives are considered, such as providers, payers, and other applicable end users. Multiple other commenters urged CMS and ONC to provide funding to HL7 FHIR Accelerators and task forces. A commenter expressed their desire for CMS to increase opportunities for greater stakeholder participation in the standards development process. Another commenter recommended that CMS release a formal assessment of the status of technology development in support of the new requirements to demonstrate that the technology is fully developed and implementable.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are an active participant in the standards development process through various workgroups and FHIR Accelerators. A few of the recommended IGs have been developed by HL7 FHIR Accelerator programs, which bring together individuals across the industry to create and adopt IGs in alignment with HL7, which allows new and revised requirements to become open industry standards. Under HL7 FHIR Accelerators, interested parties within the industry have defined, designed, and created use-case-specific implementations of FHIR to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci and CARIN, have created IGs that we recommend be used for the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs. We also provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. Further, we cohost an annual FHIR Connectathon testing event with HL7 and encourage diverse stakeholder participation from payers, providers and patient advocates. HL7 has developed a FHIR Maturity Model (FMM) 
                        <SU>179</SU>
                        <FTREF/>
                         that defines thresholds of standards maturity as part of their standards development and publication process. HL7 requires a specific maturity level for parts of the standards development and publication process. We also note that ONC publishes an Interoperability Standards Assessment (ISA).
                        <SU>180</SU>
                        <FTREF/>
                         The latest published 2023 version provides information on the HL7 standards that are required or recommended in this rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>179</SU>
                             Health Level Seven International (n.d.). Version Management Policy. Retrieved from 
                            <E T="03">http://hl7.org/fhir/R4/versions.html#maturity.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>180</SU>
                             Office of the National Coordinator for Health Information Technology (2023). 2023 Interoperability Standards Advisory Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/isa/files/inline-files/2023%20ReferenceM.A20Edition_ISA_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter urged CMS to pay close attention to principles that focus on assessing provider impact, measuring success in achieving stated goals, and monitoring standards development and use. The commenter stated that these principles can help guide CMS and developers to better respond to provider needs. Another commenter urged CMS to ensure that the technical standards meet provider and patient needs and accurately embody CMS's goals to improve care and reduce provider burden.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We will continue to assess standards development and use as an active participant in the HL7 community and FHIR workgroups. We also encourage stakeholders to participate and contribute to the work of the SDOs in the standards development and evolution, because broad engagement would support the improvement of interoperable standards.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended continued Federal support of ongoing standards development and data interoperability work, including financial and technical support, for SDOs such as the HL7 Da Vinci Workgroup, FAST, and other applicable workgroups. Some commenters encouraged CMS to advance the FAST initiatives to address the ongoing challenges of patient matching, identity management, security and authentication, and access to the necessary digital endpoints. Another commenter expressed support for incentives and investment in FHIR-based pilots and technology, stating that this would move the industry towards FHIR APIs for real-time information exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree and intend to continue our support for and participation in various standards development activities. As noted previously, we provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. We believe that the policies that we are finalizing are a crucial step in moving the industry towards real-time information exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that to assist providers in making informed decisions, CMS should apply the same “discrete data element standards” the agency applied to the original Patient Access API to the new prior authorization data added to the Patient Access, Provider Access, and Payer-to-Payer APIs. Another commenter requested that CMS consider synchronizing the required technical standards for those three APIs given that the APIs are functionally identical. The commenter stated that having a single standardized API for the three different access types (patient, provider, and payer) would provide three key benefits: (1) simplifies the technical approach for initial rollout and any future changes; (2) allows Medicaid programs to focus on challenges that these APIs pose; and (3) reduces end user confusion since end users will see the same data shared through the APIs. A commenter requested that CMS continue to standardize and harmonize API requirements to reduce potential burden for providers and confusion for consumers. Another commenter stated that these requirements should be consistent across all stakeholders.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Each of the APIs in this rule will require sharing only structured documentation, except for the Payer-to-Payer API, which includes unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request. We intentionally based the requirements for the Provider Access and Payer-to-Payer APIs on the content requirements for the Patient Access API, to facilitate reuse, since payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. Payers already devoted the development resources to build a FHIR API infrastructure when they implemented the Patient Access API, which can be adapted for additional interoperability use cases. While the data we are requiring to be shared via these APIs would be nearly identical, they have different use cases, thus necessitating separate API regulatory requirements. We also encourage payers to reuse infrastructure for all the APIs. Payers may implement the API functionality by using one or multiple APIs, depending on their approach, as long as all 
                        <PRTPAGE P="8932"/>
                        requirements are met for each of the APIs.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS align the technical standards provisions outlined in this rule with the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). A commenter recommended that CMS work with ONC to do so. Another commenter stated that they support both rules and urged CMS to ensure that there are no duplicative efforts. Another commenter recommended removing the prior authorization provisions outlined in the HIPAA Standards for Health Care Attachments proposed rule and moving forward with finalizing FHIR-based standards and transactions. Another commenter encouraged CMS to work with ONC to align any prior authorization proposals with HHS's proposal to establish a national standard for electronic attachments.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Requirements to use certain HIPAA transaction standards for prior authorization were proposed in the HIPAA Standards for Health Care Attachments proposed rule. These are related policies, and we will ensure a path toward implementation that will allow payers and providers to comply with both. However, because that rule has not been finalized, we cannot comment on how the standards would align with the policies in this rule. If finalized, in that final rule we would discuss the impact of those policies and any opportunities to align with our policies in this final rule. We will also continue to work with ONC on alignment between standards in this rule, and other standards adopted across CMS.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS institute financial incentives for market suppliers, providers, and payers to participate in the testing and development of technical standards, IGs, and applicable processes. The commenter stated that one of the primary challenges of standards development and testing is a lack of financial and regulatory incentives for stakeholders to participate, which then slows down testing. Multiple commenters cautioned CMS to consider the cost of establishing the proposed API infrastructure. Another commenter noted that implementation will require integration between the newly acquired API functionality and the existing data sources, which includes exporting data from current systems to be imported and stored within a FHIR-compliant repository so that it can be presented via the API to the user. Multiple commenters requested that CMS provide technical assistance and resources to help the industry implement the APIs and meet all the technical standards and requirements outlined in this rule. Another commenter requested that CMS engage with stakeholders to develop resources and technical assistance to help industry operationalize and meet the proposed technical standards and API requirements outlined in the rule and any other parallel agency efforts.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         At this time, we lack statutory authority to provide financial incentives to participate in the testing and development of technical standards, IGs, and applicable processes. While we do not currently provide funding for IT infrastructure development costs (except for Medicaid agencies, as discussed in section II.E. of this final rule), we do provide educational webinars providing overviews of the technical requirements in the interoperability rules. Additional public resources also exist through HL7, such as their Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings that are generally available. We also cohost an annual Connectathon with HL7, which is free for stakeholders to attend. Ultimately, each payer is responsible for ensuring that their users are trained on their systems.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that a frequent problem is that there is not a well-established or monitored mechanism for an implementer to contact a payer about implementation issues or implementation questions. The commenter stated that this is an important missing piece to making widespread implementation viable. The commenter reflected on the experience of third-party apps engaging with payers to implement the existing Patient Access API. They stated that third-party apps struggle with finding someone to fix issues, answer questions, approve their registrations, and address other barriers to implementation they experienced.
                    </P>
                    <P>Multiple commenters stated that to support the proposed APIs, provider and payer endpoints must be included in a national directory, available to support endpoint discovery, before the compliance dates of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter stated that a CMS NDH should be initiated to help find provider and payer endpoints. Another commenter stated that the lack of an authoritative central directory could create a significant gap in the ability for industry to move many critical interoperability initiatives forward. Another commenter stated the proposed technical standards for APIs is a helpful step to greater interoperability; however, CMS failed to properly account for the complexity of this implementation. The commenter recommended that CMS should implement a national directory so that each plan and provider must maintain only one incoming/outgoing connection.</P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge commenter concerns that there is not a monitored mechanism for contacting a payer about implementation issues or implementation questions. We thank the commenters for their concern that the lack of an authoritative central directory is a gap in the ability to move forward with interoperability initiatives. We do understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization APIs policies, and as discussed in section I.D. of this final rule we are committing to exploring an NDH that contains payers' digital endpoints in support of the Payer-to-Payer API and providers' digital endpoints. We will also explore including payer contact information, including whom to contact regarding API implementation issues or questions, in any NDH we propose.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that adding standard data classes and data elements around high-priority use cases is an effective strategy to make data more accessible to consumers. The commenter noted that the Provider Directory and Patient Access APIs can serve as a base for the other proposed APIs. The commenter provided recommendations to help CMS achieve this goal such as establishing operational standards to help developers, requiring payers to register app developers and grant authorization to production access without regard to out-of-band consent standards payers choose to implement, and establishing stronger requirements for payers to make this information available. The commenter also recommended that (1) CMS require impacted payers to establish sandbox environments; (2) CMS impose a reasonable time standard to mitigate implementation delays; (3) CMS require impacted payers to perform conformance tests and report results to the public; and (4) CMS require that impacted payers' technical documentation for the Patient Access API notes what USCDI data are made available. Another commenter recommended that CMS should develop a roadmap in partnership with the private sector for all the technical use cases outlined in the proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the additional suggestions, however, many 
                        <PRTPAGE P="8933"/>
                        of those were not proposed and therefore, we cannot include such provisions in the final rule. We also understand the value of a sandbox environment and acknowledge the value of payers establishing sandbox environments for implementers to test; however, we realize there are industry costs to doing so.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters encouraged CMS to consider alternative approaches to achieving data exchange. A commenter recommended that CMS consider other types of interoperability technology beyond APIs and request/response data exchange, which can lead to multiple copies of data. The commenter suggested CMS consider services that provide virtual real-time data updates. Another commenter recommended that CMS work with ONC to develop a future-looking approach to allow consumers to direct the sharing of claims data with third-party entities via a national exchange platform. A commenter recommended that CMS, ONC, and HL7 work together to build the infrastructure for a standard for ADT data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we appreciate the commenters who asked us to consider services that provide virtual real-time data updates and we recognize the importance of needing the patient information as soon as possible or in real time, we also believe that requiring that at this time would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able. We understand the concern over duplicative information, and it is not our intention to increase provider burden sharing data through the APIs referenced in this final rule. There are IT solutions available for providers' EHRs or practice management systems, such as SMART on FHIR apps, which can make the data received via the APIs actionable and avoid duplicative information. We also note that standards for ADT data are outside the scope of this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter highlighted that health IT challenges can sometimes be larger than they appear. The commenter stated that regulatory requirements can be tailored to coincide with health IT functionalities that are currently available to support organizations in accomplishing interoperability in a more affordable way.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenter for their input and will continue to closely coordinate with industry to decrease implementation burden wherever possible.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter urged CMS not to finalize the interoperability proposals until stakeholders have had a chance to review and comment on ONC's HTI-1 proposed rule, which was still under review at the Office of Management and Budget (OMB) at the time of publication of the CMS Interoperability and Prior Authorization proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We recognize that commenters are interested in ONC policies that relate to the policies in the proposed rule. ONC has since published the HTI-1 final rule. While related, these rules address separate areas of CMS and ONC authority. We are not finalizing any modifications from the proposed rule based on HTI-1 other than updating our regulatory citations and incorporating expiration dates ONC has finalized for particular standards at 45 CFR 170.215. Therefore, we did not offer an additional comment period.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed appreciation for CMS not requiring health IT certification for the interoperability requirements outlined in this proposed rule. A commenter stated that establishing certification criteria based on the current HL7 Da Vinci IGs is premature. The commenter noted that providers must use data from CEHRT for the electronic prior authorization measure, which will serve as a spur for adoption of certified health IT. Another commenter noted that some of the proposed APIs require multiple health IT systems to interact and support a complex workflow and stated that establishing a certification approach using functional capabilities would be challenging, and encouraged CMS to engage with providers and payers to gather information to establish a well-defined and scalable set of guidelines and capabilities.
                    </P>
                    <P>Opposite to that, a commenter recommended that CMS work with ONC to incorporate new standards and requirements for API use by EHR vendors as certification criteria in the ONC Health IT Certification Program.</P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose and are not finalizing any other requirements related to certification under the ONC Health IT Certification Program in this final rule. However, we note that the Unified Agenda, at the time of this final rule's publication, includes an entry for a proposed rule from ONC (RIN 0955-AA06).
                        <SU>181</SU>
                        <FTREF/>
                         The description indicates that that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization. We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to the Certification Program in future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>181</SU>
                             Office of Information and Regulatory Affairs (n.d.). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from 
                            <E T="03">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&amp;RIN=0955-AA06.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS should establish a consistent set of technical standards between the TEFCA and CMS-required APIs so that the industry does not have to implement multiple different standards depending upon the exchange partner or mechanism for exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to section II.B. of this final rule for a discussion on the interaction between policies that require API development or enhancement and TEFCA.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended CMS consider a policy requiring third-party payers, benefit managers, and any other party conducting utilization management to accept and respond to standard electronic prior authorization transactions for pharmacy benefits that use a nationally recognized format, such as the NCPDP SCRIPT standard. Similarly, another commenter stated that CMS should encourage health IT vendors and developers to provide retail pharmacies with technical IT infrastructure to bridge the gap between pharmacy claim systems and medical benefit claims systems and noted that many retail pharmacies only utilize the NCPDP standards and do not have the capability to enroll as DME suppliers and submit claims using X12 transactions. Another commenter recommended that CMS explore the need to designate an electronic transaction standard for drugs covered under a medical benefit.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate stakeholders' interest in pharmacy standards and bridging the gap between pharmacy and medical benefit systems and we recognize the need to do so in the future. However, as noted in section I.D.3., standards for data exchange for any pharmacy claims and drugs covered under medical benefits are excluded from our policies and out of scope for this rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that under the ONC Health IT Certification Program, APIs must be registered within 15 days (45 CFR 170.315(g)(10)). However, the commenter stated that CMS did not impose any registration requirements for the proposed payer 
                        <PRTPAGE P="8934"/>
                        APIs. The commenter recommended that CMS should consider imposing a reasonable registration period for APIs to address delays reported by CARIN members throughout the onboarding and authorization process to acquire test accounts, sandbox access to test API connections, and troubleshooting support.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose registration deadlines as a requirement for payer APIs in the same fashion as the health IT certification criterion at 45 CFR 170.315(g)(10), such that Health IT Modules certified to 45 CFR 170.315(g)(10) must register patient-facing applications within 15 days (per associated requirements at 45 CFR 170.404(b)); however, we acknowledge that such requirements can help to support the usability of APIs. We may further explore how to incorporate registration deadlines into our API requirements in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended setting an implementation date before January 1, 2026, and mandating HL7 FHIR Release 4.0.1. The commenter also recommended operational enhancements for payers such as payers allowing longer lifespans on access tokens, payers not imposing unsupported security and authentication workflows, and payers supporting test accounts and synthetic data in production environments. The commenter noted that these recommendations would dramatically improve access to data from available open APIs while setting standards for payers and their interoperability vendors to follow.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         HL7 FHIR Release 4.0.1 has already been adopted by HHS in the ONC Cures Act final rule at 45 CFR 170.215 (85 FR 25521). We will continue to work with payers on testing and implementation of their interoperability APIs through FHIR Connectathons and encourage stakeholders to participate in FHIR workgroups. We will explore additional enhancements through future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended using the most recently approved HL7 Da Vinci IG that supports HL7 FHIR Release 4.0.1. The commenter stated that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenter for their recommendation, but we disagree that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1, as the SMART App Launch IG is built on top of the FHIR Release 4.0.1 specification itself. The SMART App Launch IG specifies a number of capabilities, including user authentication and authorization, back-end service authentication, application launch, and context sharing, that systems can use to interact within the FHIR R4 standard.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter sought clarification on the use case for the Bulk Data Access IG for the Patient Access API, since one of the biggest challenges for EHR vendors today is determining how to handle inbound data exchanged via the FHIR standard.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We did not propose, nor are we finalizing, a requirement to require the Bulk Data Access IG for the Patient Access API.
                    </P>
                    <HD SOURCE="HD3">b. Additional Implementation Guide Discussion</HD>
                    <P>In the proposed rule, we discussed that several of the recommended IGs, such as HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG, build on specific profiles within the US Core IG (87 FR 7615). Following the publication of the HTI-1 final rule, at 45 CFR 170.215(b)(1) there are two adopted versions of the US Core IG: the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)), until this standard expires on January 1, 2026, and the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)). We only proposed to require US Core STU 3.1.1 because it was the only version adopted at the time of the proposed rule. However, we recognize that some of the recommended IGs (and subsequent versions) may use profiles added in US Core IG STU 6.1.0. Payers can use updated versions of the recommended IGs that rely on newer versions of the US Core IG, if those updated versions meet our existing requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25532), as discussed further below.</P>
                    <P>Specifically, in the proposed rule, we recognized that the data content for each API may only require a subset of the profiles defined within the US Core IG and gave examples (87 FR 76314-76315). While we want to ensure that implementers' systems create FHIR resources conformant to the US Core IG, where applicable, to support interoperability across implementations, we also do not want to require payers to engage in unnecessary development. Therefore, we proposed and are finalizing that impacted payers are only required to use technology conformant with the US Core IG, where applicable (that is, where there is a corresponding FHIR resource to the data content requirements for the API). If a FHIR resource is part of the required data content and has been profiled by the US Core IG, then the payer must support the FHIR resource according to the FHIR resource profile's “Structure Definition” in the US Core IG. For example, because the “Patient” FHIR resource is required in the Patient Access API, the “Patient” FHIR resource must conform with the “US Core Patient Profile,” including all the “mandatory” and “must support” requirements specified in the US Core IG.</P>
                    <HD SOURCE="HD3">c. Using Updated Versions of Required Standards</HD>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25510), we established that impacted payers could use an updated version of a required standard for the Patient Access or Provider Directory APIs under certain conditions. Payers may use updated versions of standards at 45 CFR 170.213 and 170.215 if the following conditions are met: (1) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, (2) the updated version of the standard does not disrupt an end user's ability to access the required data via that API, and (3) the updated standard is not prohibited by law (85 FR 25522). Payers may use an updated version if required by other applicable law. We proposed to extend this policy to allow payers to use updated versions of a standard to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Under that proposal, impacted payers could upgrade to newer versions of the required standards, subject to those limiting conditions (87 FR 76315).</P>
                    <P>One of those conditions for using updated versions of the standards at 45 CFR 170.213 and 170.215 is that the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. The National Coordinator approves updated versions of standards in the ONC Health IT Certification Program through SVAP, pursuant to 45 CFR 170.555, which was finalized in the ONC Cures Act final rule as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards so long as specific conditions are met, providing a predictable and timely approach within the ONC Health IT Certification Program to keep pace with the industry's standards development efforts.</P>
                    <P>
                        Under SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in 
                        <PRTPAGE P="8935"/>
                        an open and transparent process to timely ascertain whether a more recent version of an adopted standard or implementation specification should be approved by the National Coordinator for developers' voluntary use in the ONC Health IT Certification Program. ONC publishes updated versions of standards under consideration for SVAP and lists the updated versions of standards that the National Coordinator has approved as part of the Interoperability Standards Advisory on 
                        <E T="03">HealthIT.gov</E>
                        .
                        <SU>182</SU>
                        <FTREF/>
                         Members of the public can use this resource to review standards that may be approved through SVAP in the future, as well as provide input on which updated versions should be approved. We encourage impacted payers to review these resources to better understand how updated versions of the standards at 45 CFR 170.213 and 170.215 may be approved by the National Coordinator through SVAP and become available for payers to use in their APIs, provided other specified conditions for using updated standards are met. Several updated versions of the standards currently at 45 CFR 170.213 and 170.215 have been approved by the National Coordinator through SVAP,
                        <SU>183</SU>
                        <FTREF/>
                         including USCDI v2 and v3; US Core IG STU 4.0.0, 5.0.1, and 6.1.0; SMART App Launch IG Release 2.0.0; and Bulk Data Access IG v2.0.0: STU 2. As soon as the National Coordinator approves updated versions through SVAP, we consider the updated versions to have met this condition for use by impacted payers for our API requirements. We emphasize that if impacted payers choose to use updated standards, it must not disrupt an end user's ability to access the required data. We are finalizing this proposal, as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>182</SU>
                             Office of the National Coordinator for Health Information Technology (n.d.). SVAP. Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/standards-version-advancement-process</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>183</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for CMS's proposal to allow flexibility for payers to use updated versions of certain standards and specifications required for APIs in the proposed rule. A commenter expressed support for aligning standards between the Patient Access, Provider Access, and Payer-to-Payer APIs, as this ensures data compatibility between use cases. Another commenter stated that the standards and specifications at 45 CFR 170.215 are more advanced and better aligned with present efforts to streamline prior authorization workflows by leveraging HL7's FAST work. Another commenter stated that these standards support widespread interoperability, ease implementation, and minimize complexity and costs. A commenter expressed strong support for CMS's efforts to promote portability of patients' EHI between providers and payers to assure continuity of care by further building on the common standards platform of FHIR APIs using USCDI, where applicable. Multiple commenters expressed support for the continued alignment between CMS and ONC regarding updates to technical standards and specifications through the rulemaking process.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge and thank commenters for their support of our policies.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that CMS's approach to mandating technical standards by referencing specific standards in regulation is novel for health information exchange. The commenter stated that prior data exchanges, such as the HIPAA standard transactions or the machine-readable files, have everything defined in the named specifications and not defined by reference to another standard in regulation. The commenter stated that having standards specified elsewhere allows for the referenced standards to be changed which would then have the cascading effect of requiring changes in all the APIs on the timeframe of the standard change for the APIs to remain conformant. The commenter disagreed with this regulatory approach and stated that it is better to have each API specified separately and to be self-contained (that is, not having referenced standards). The commenter stated that this way individual APIs could be evaluated for change on their own merits, as standards in the HIPAA Standards for Health Care Attachments proposed rule are currently being evaluated with the potential change in the version for the X12 278 transaction standard for attachments under HIPAA (version 6020) or for the X12 837 transaction standard for claims, and the X12 835 transaction standard for remittance advice being recommended by X12 for consideration to X12 8020 transaction standard for plan premium payments, or the recommended upgrade of three other X12 transactions to version 8030, including claim status, health plan enrollment, and health plan premium payments.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's concerns regarding the timing of updates to required standards via reference to other regulations. We intend to collaborate with ONC to ensure updates to standards are deployed with reasonable timeframes and sufficient advance notice for payers to make any required updates to their APIs. Aligning with the HHS-adopted API standards and associated implementation specifications at 45 CFR 170.215 is important to ensure consistency. We are finalizing the versions of the required standards that were at 45 CFR 170.215 at the time of this proposed rule. However, ONC has since finalized the HTI-1 final rule (89 FR 1192), which adopted updated versions of certain standards including the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215 (b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170. 215(c)) to indicate when a version of a standard may no longer be used. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to the API compliance dates. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed below.
                    </P>
                    <P>The update and review process for HIPAA transaction standards follows a statutory review process but does not include the same testing and balloting process we require for the standards and IGs. Furthermore, the HL7 standards and IGs adopted by ONC may be updated for use in the ONC Health IT Certification Program through the SVAP. We rely on this flexibility in our update policy by allowing payers to use versions of standards at 45 CFR 170.213 and 170.215 that have been approved by the National Coordinator, enabling a nimble approach to industry testing and innovation. This does not currently exist under the HIPAA standard transaction reference model process.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS update the clinical data requirements to USCDI v2. The commenters also recommended that CMS give guidance on if and when USCDI v3 and v4 may be required. The commenters noted that use of these updated standards would advance health equity and public health work. A commenter strongly recommended that impacted payers incorporate data elements identified in a newer version of the USCDI, specifically USCDI v3, instead of the proposed USCDI v1. The commenter noted that USCDI v1 does not constitute an elaborated list of data 
                        <PRTPAGE P="8936"/>
                        elements compared to the most recent versions, which incorporate elements that play a critical role in electronic data exchange. Another commenter requested CMS and ONC provide guidance regarding using newer versions of USCDI and associated US Core IG. The commenter noted that this guidance will be helpful when multiple versions of the USCDI are available for use, so all third-party app developers have clear expectations and understanding regarding what data they need to be able to share and receive.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed in section II.A.2.d., we are finalizing a change to the required data content for the Patient Access, Provider Access and Payer-to-Payer APIs to a standard listed at 45 CFR 170.213. At the time of the CMS Interoperability and Prior Authorization proposed rule, USCDI v1 was the only version of the USCDI adopted at 45 CFR 170.213. However, ONC has since published the HTI-1 final rule, which establishes a January 1, 2026, expiration date for USCDI v1 and adopts USCDI v3 at 45 CFR 170.213. After January 1, 2026, USCDI v3 would be the only version specified at 45 CFR 170.213 that has not expired (89 FR 1192). In this way, the required version of the USCDI for the APIs in this final rule will advance in alignment with versions adopted by ONC in 45 CFR 170.213. When more than one version of USCDI is adopted at 45 CFR 170.213 and have not expired, payers may conform to either version.
                    </P>
                    <P>
                        As stated previously in this section, we are also finalizing our proposal that an updated version of a standard could be used if it is required by other law, or if ONC has approved the updated version for use in the ONC Health IT Certification Program, users are able to access the required data via the API, and it is not prohibited by other law. In order to identify updated standards that have been approved for use in the ONC Health IT Certification Program, payers can review the standards approved through the SVAP on ONC's website 
                        <E T="03">https://www.healthit.gov/isa/standards-version-advancement-process,</E>
                         as well as standards that are being considered for approval through SVAP (new standards for SVAP are approved annually).
                    </P>
                    <P>
                        We note that USCDI v2 was approved in the 2022 SVAP cycle, while USCDI v3 was approved as part of the 2023 SVAP cycle.
                        <SU>184</SU>
                        <FTREF/>
                         We also note that several updated versions of the US Core IG subsequent to the required US Core IG STU 3.1.1 have been approved by the National Coordinator through the SVAP and are available for payers to use under this policy, including US Core IG STU 4.0.0, 5.0.1, and 6.1.0.
                        <SU>185</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>184</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>185</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap</E>
                            .
                        </P>
                    </FTNT>
                    <P>The US Core IG is updated annually to reflect changes to the USCDI, and each US Core IG version is built to a specific version of the USCDI. For instance, US Core IG STU 3.1.1 is built to USCDI v1 and the US Core IG STU 6.1.0 is built to USCDI v3. As the recommended IGs continue to be refined and advance, they may reference different versions of the US Core IG based on updated versions of the USCDI. Implementers are encouraged to adopt the newer versions of the recommended IGs as they are published. Consistent with our final policies to allow payers to use updated standards at 42 CFR 170.215 if they have been approved by the National Coordinator for use in the ONC Health IT Certification Program and other conditions, implementers may use updated versions of US Core referenced to the specifications in recommended IGs. HL7 and the FHIR Accelerators are aware of these concerns and are working on an approach to enable greater version support for IGs.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters supported flexibility to use updated standards, such as ONC's SVAP for certified health IT developers, to allow payers to use the most current recognized versions of vocabulary standards and interoperability standards or specifications used in the certification. A commenter stated that CMS should only require new versions of standards, specifications, and IGs after testing and adequate time for implementation. Another commenter stated that the mechanism to allow implementers to advance versions of standards in this rule as long as using an updated standard does not impair access to data through the API can be used for any or all IGs used to support these APIs or related auxiliary processes (for example, patient attribution).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for this policy. The standards we are requiring in this final rule are those that we believe are sufficiently mature. We intend for future rulemaking to operate similarly. As stated, payers can implement the latest versions of the required standards and IGs as long as they meet the specified conditions, such as not impairing access to data through the API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters stated that use of specific FHIR-based standards, specifications, and IG versions should align with those approved by ONC through SVAP. A commenter stated that CMS requirements and adoption timelines should remain coordinated with ONC's progression. The commenter suggested that CMS use a more general reference to the ONC Health IT Certification Program and SVAP. Another commenter stated that ONC will be providing a more current set of standards and specification versions soon through ONC Health IT Certification Program updates. The commenter stated that it is imperative that CMS require developed APIs to conform to the most recently approved SVAP standards within 12 months of approval. The commenter also recommended that CMS coordinate with ONC to include more standards and IGs in the SVAP to align with the rule. The commenter also recommended that CMS include a transition period (for example, 12 months).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters feedback and remind readers that under this final rule, in addition to our coordination with ONC, payers are permitted to voluntary use updated standards provided it does not disrupt an end user's ability to access the data available through the API. In addition, implementers may advance to those standard versions approved by the ONC through SVAP.
                    </P>
                    <P>We decline at this time to set a timeline by which we would require impacted payers to use the updated version of the standard rather than the adopted version of the standard. We believe the voluntary nature of the SVAP supports a transitional period—also a request from commenters—by allowing for a flexible implementation of standards versions between regulatory cycles during which ONC revises the adopted version to the latest update for each standard. We will continue to engage with patients, providers, payers, health IT developers, and our Federal partners to ensure that this approach balances the need to advance standards with the need for flexible transition periods for updates. We will also continue to work with ONC in their efforts to support HHS and the health care industry through the advancement and adoption of interoperable standards and implementation specifications for a wide range of health IT use cases.</P>
                    <P>
                        We support innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements. Thus, we also sought comment on the process we 
                        <PRTPAGE P="8937"/>
                        should use to adopt or allow new versions of standards and implementation specifications over time. We received many comments in response to our request for comment and will consider this feedback for future rulemaking and guidance. We are finalizing the proposal to allow payers to use an updated standards, specifications, or IGs if required by law, or if the updated standard, specification, or IG is approved for use in the ONC Health IT Certification Program, do not disrupt an end user's ability to access the required data, and is not prohibited by law for each of the APIs at the CFR sections listed in Table H2.
                    </P>
                    <HD SOURCE="HD3">3. Recommended Standards To Support APIs</HD>
                    <P>In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted that there are publicly available IGs that provide implementation information that impacted payers can use to meet the regulatory requirements for these APIs. Using those IGs supports interoperability and allows impacted payers to avoid developing an approach independently, which could save time and resources. In this final rule, we are recommending specific IGs that are relevant to each of the APIs, which may be used in addition to the required standards at 45 CFR 170.215.</P>
                    <P>In the December 2020 CMS Interoperability proposed rule, we proposed to require impacted payers to use certain IGs, including the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) IG, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG, and HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs in that proposed rule. As discussed in section I.A. of this final rule, we are withdrawing the December 2020 CMS Interoperability proposed rule. We also noted that these IGs continue to be developed and refined through the HL7 ballot and standard advancement process to better support the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs.</P>
                    <HD SOURCE="HD3">a. Recommending vs. Requiring Implementation Guides</HD>
                    <P>In the CMS Interoperability and Prior Authorization proposed rule, we proposed to recommend CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for specific APIs, as listed in Table 10 of the proposed rule (87 FR 76320). We also solicited comments on whether CMS should propose to require these recommended IGs in future rulemaking and other ways that we could support innovation and interoperability. We emphasize that while we are not requiring payers to use the recommended IGs listed in Table H3, we may propose requiring payers to use these and other IGs in future rulemaking, should they reach sufficient maturity.</P>
                    <P>After careful consideration of the versions of the IGs that were available at the time of the proposed rule, we determined that we were not ready to propose them as requirements. We stated that we believed these IGs would continue to be refined over time as interested parties have opportunities to test and implement them, and as such, we chose to recommend them rather than require them. Specifically, we stated we would continue to monitor and evaluate the IG development and consider whether to propose them as a requirement at some future date. In this final rule, we are finalizing our recommendation to use the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs, as applicable and listed in Table H3. We also note that several of the recommended IGs have had updated versions published since the CMS Interoperability and Prior Authorization proposed rule. Thus, we have updated Table H3 accordingly to represent the most recent published versions of the recommended IGs. Because these are only recommended IGs, we do not codify version updates through rulemaking.</P>
                    <P>We acknowledge that by recommending rather than requiring certain IGs, there is potential for implementation variation that could limit interoperability and ultimately lead to rework for implementers if requirements are introduced later. However, we concluded at the time of the proposed rule that it was more important to not require the IG versions available at that time due to the maturity of the versions available. We recommended, but did not propose to require, these IGs because we wanted to ensure that implementers can use subsequent versions of these IGs without being restricted to the version available when we issued the notice of proposed rulemaking. As discussed in section II.G.2.c. of this final rule, we are finalizing a provision to allow payers the flexibility to use updated versions of certain standards required for the APIs in this final rule. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76316), we acknowledged that subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement that an updated standard must not impair access to data through the API. We intend to monitor IG development and may propose to require specific IGs at a future date and/or allow for voluntary updates under our flexibility policies. We received comments on our decision to recommend, rather than require the listed IGs in the proposed rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters appreciated CMS's decision to recommend rather than require the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs. A commenter supported CMS's decision to recommend instead of requiring IGs given that some of the standards and IGs are not yet mature enough for industry adoption. Another commenter appreciated CMS's decision to recommend rather than require IGs due to the interplay between this rule and the HIPAA Standards for Health Care Attachments proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support of our decision to recommend certain IGs in the proposed rule, which we believe balanced the need to provide guidance and flexibility to industry as standards advance.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple other commenters supported the recommended IGs, but noted concern that these IGs do not have enough outside involvement in the development phase, which could result in gaps in workflows. However, the commenters noted that they are confident that the HL7 Accelerator workgroups will provide the necessary maturity if given sufficient time.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         These standards development activities do have outside parties involved throughout the standards development process. We encourage all interested parties, especially those who already have the experience implementing the APIs, to engage with the process. HL7 and the Accelerators welcome and solicit feedback for all of their IGs and specifications. Meeting participation is largely open to the public, and one does not have to be a member to participate in testing events and many other standards development activities.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters disagreed with CMS's decision to recommend rather than require the IGs and expressed concern for CMS's decision to not require certain IGs, with 
                        <PRTPAGE P="8938"/>
                        one concerned that not requiring the IGs will impact the level of interoperability necessary to support data exchange. Commenters urged CMS to consider the potential for implementation variation in APIs and limit industry-wide interoperability. Multiple commenters expressed that it is important that adherence to IG requirements is required, not just encouraged, to ensure the industry adopts these to obtain the benefits of the near real-time Prior Authorization API transactions. Another commenter recommended that CMS adopt and require IGs as quickly as possible. The commenters stated that without IGs, there is a risk that early work done by health IT developers and the health care community will have to be refactored or restarted to meet the IG guidelines. A commenter stated that CMS should act swiftly to encourage the creation of more appropriate IGs and recommended that CMS work with payers to create electronic systems and interfaces that are consistent and easy to use.
                    </P>
                    <P>Another commenter stated that not requiring certain IGs is not in line with the interoperability goals and prior authorization initiatives outlined in this rule to obligate providers to report on their adoption of this technology if that technology will not be uniformly adopted and implemented between different payers. A commenter stated that it is critical that all data contributors be held to the same set of rules and required to adopt the same standards and IGs. To ameliorate this, the commenter recommended that the IGs be required rather than recommended, and that a mere recommendation may result in more burden and duplicative work. A commenter stated that because CMS is not requiring certain IGs, it is unfair and contrary to the goals of these interoperability and prior authorization initiatives to obligate MIPS eligible clinicians, eligible hospitals, and CAHs to report on their adoption of this technology when that technology will not be uniformly adopted and implemented between different payers.</P>
                    <P>Multiple commenters recommended that CMS require impacted payers to use the CARIN for Blue Button, HL7® FHIR® Da Vinci Patient Coverage Decisions Exchange (PCDE), PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs while allowing for adaptability and advancement of those IGs over time. A commenter stated that requiring certain IGs would move payers toward standardized data exchange. A commenter noted that most of the IGs have been around for several years, and most have been tested in multiple Connectathons, pilot projects, and in production environments. The commenter believes having consistent, well-understood data fields with clear meaning that everyone uses the same way is a key element of any API or any successful data exchange. The commenter stated that using standard IGs would move industry toward interoperable data exchange.</P>
                    <P>
                        <E T="03">Response:</E>
                         We received a significant number of comments on both sides regarding requiring IGs and not requiring IGs, which indicates that there is not broad agreement across the industry. In the proposed rule, we sought to strike a balance by requiring the standards and IGs adopted at 45 CFR 170.215 in alignment with ONC and recommending additional IGs for each API implementation. We acknowledge that by not requiring all the available IGs, there is potential for implementation variation in these APIs that could limit interoperability and ultimately lead to re-work for implementers if requirements are introduced later. However, at the time of the proposed rule, we believed it was more important not to require these IGs while they were still undergoing additional enhancements. We disagree with the concern that our decision to not propose to require certain IGs is unfair and contrary to the goals of these interoperability and prior authorization initiatives of this final rule. The required standards at 45 CFR 170.215 mean that impacted payers must implement these APIs using the FHIR standard, which will advance interoperability. We continue to strongly recommend using the other recommended IGs listed in Table H3.
                    </P>
                    <P>As stated previously, we also believe that the approach in the proposed rule of recommending, but not requiring, the specific IGs and versions provided directional guidance with flexibility to the industry in order to allow for additional improvements to be made without locking implementers into versions of the IGs available at the time of the proposed rule. Under the recommendations in the proposed rule, as these IGs progress, industry could continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready through updates to CMS policy. To not identify any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations provide direction to implementers.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the development and maintenance of standards and IGs are an extension of Federal policy that does not go through the rulemaking process. They noted that it is critical that this development and maintenance process be consensus-based, fair, transparent, and open to all stakeholders. The commenter continued by stating that the IG creation process is currently driven by a limited number of volunteers that do not broadly represent the industry, which results in IG resource and profile versioning issues. The commenter stated that CMS should ensure there is no fee to fully participate in the process for the regulatorily required exchanges and relying on an American National Standards Institute (ANSI)-accredited process to develop the IGs would improve the approach.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that standards and IGs are not developed through the rulemaking process. Rather, standards and IGs go through the rulemaking process if and when they are proposed to be adopted. We also appreciate that commenters are invested in the quality of the IGs and the SDO, and affirm, as we stated in the CMS Interoperability and Patient Access final rule (85 FR 25540), that development and maintenance of standards are the purview of SDOs, and that interested parties, including Federal agencies, participate in that process. Stakeholders have the opportunity for review and comment on the standards both at the time they are being developed, as well as during the proposed rule comment period. HL7 is an ANSI-accredited 
                        <SU>186</SU>
                        <FTREF/>
                         SDO, and Da Vinci is an accelerator workgroup under the umbrella of HL7 and operates under the same rules of all ANSI accredited SDOs in the manner in which they obtain consensus on standards. Furthermore, HL7 standards are free and open-source, and documentation is available to anyone to ensure that all developers can equally access information. Using these freely available materials will reduce the development burden for both payers and app developers and facilitate industry-wide interoperability. Similarly, participation in online working meetings and providing feedback as part of the standards development process is free, and diverse organizational representation is critical to the quality of the standards and IGs. Thus, we encourage as many organizations as possible with a stake in the development and quality of these guides to participate. HHS uses different authorities to adopt and require standards that are developed and 
                        <PRTPAGE P="8939"/>
                        maintained by organizations such as HL7 using the processes described previously. For instance, ONC has adopted the standards and implementation specifications at 45 CFR 170.215 cross-referenced in this final rule under the authority of section 3004 of the Public Health Service Act.
                    </P>
                    <FTNT>
                        <P>
                            <SU>186</SU>
                             ANSI oversees standards and conformance of processes for all SDOs. 
                            <E T="03">See</E>
                             American National Standards Institute (2023). ANSI. Retrieved from 
                            <E T="03">https://ansi.org/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested CMS emphasize that using the IGs is not limited to literal use, but also interpretive use to model interactions within the respective health IT configuration in a way that is illustrative rather than prescriptive.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         IGs contain both SHALL and SHOULD statements, which respectively indicate whether health IT systems must meet certain requirements to conform to the IG or are just strongly recommended to. While implementers will be required to conform with the required IGs we are finalizing, we remind readers that the recommended IGs can be implemented as they see fit as long as they meet the requirements of the API.
                    </P>
                    <HD SOURCE="HD3">b. Implementation Guide Maturity</HD>
                    <P>In the proposed rule, we welcomed further information about the maturity of the recommended IGs, including considerations about further development that may be needed prior to us proposing to require the IGs we recommended (87 FR 76317).</P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed concern regarding the maturity, scalability, and real-world testing of the IGs recommended in the proposed rule. Multiple commenters were concerned that there may be compatibility issues between the current and future versions of the IGs given that the IG versions are not currently finalized. A commenter stated that slight variations in API implementation could significantly increase burden placed on the provider community. A commenter recommended that CMS and ONC issue guidance on what could be expected in the IG guidelines to inform early work and to encourage as much fidelity to these IGs as possible.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are committed to continuing to work with HL7, the Accelerators, and interested parties within the industry to define, participate in, and convene testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity. We acknowledge that, as with any standard, potential compatibility issues could arise throughout development. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, increasing with the level of use and adoption. As IGs mature, the number of potential compatibility issues between versions is expected to decrease. Likewise, as IGs continue through the standards development process, they will be enhanced to address areas of variance among payers that are barriers to interoperability. We determined that it was important to recommend these IGs to move the industry and provide direction towards a common set of specifications, as opposed to not including these recommendations, which would lead to a greater number of variations and cause a greater burden.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS explain that support for SMART Backend Services specification is also required with the Bulk Data Access IG. Another commenter stated that significant limitations exist for the Bulk Data Access IG and OpenID Connect Core standard. The commenter noted that it is unknown when the Bulk Data Access IG will be ready for implementation and use on a large scale.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The Bulk Data Access IG v1.0.0: STU 1 includes the option for SMART Backend Services specification to enable system-to-system authentication and authorization of backend services. The Backend Services specification that was included in Bulk Data Access IG v1.0.0: STU 1 was moved to SMART App Launch IG Release 2.0.0. Therefore, we strongly recommend that the SMART Backend Services specification of the SMART App Launch IG Release 2.0.0 be supported and thus have included this recommendation for both the Provider Access and Payer-to-Payer APIs in Table H3. We acknowledge that not all connections may use backend services, but when such services are available, payers may wish to use the HL7 SMART Framework. More recent versions of the SMART App Launch IG specification, starting with Release 2.0.0, incorporate the SMART Backend Services, which ONC has adopted in the HTI-1 final rule at 45 CFR 170.215(c). We further remind readers that though we are requiring impacted payers to support Bulk Data Access IG for the Provider Access and Payer-to-Payer APIs in this final rule (Table H3), payers are free to set their own criteria for using bulk data exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended that CMS delay API implementation until the recommended IGs are ready to be required. The commenter noted that the proposed APIs are not feasible without standardized adoption and expressed concern that the necessary IGs to implement the APIs are not mature, tested, or ready to scale. A commenter suggested that CMS should work with interested parties across the health IT community to propose and finalize IGs that are not mature prior to mandating their use.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We remind readers that we are finalizing 2027 compliance dates for the policies that require API development and enhancement partly to allow industry additional time to implement the needed functionality within their internal systems. By requiring some IGs and recommending others, we believe that we achieved the appropriate balance between moving industry forward, while allowing flexibility for continued development of IGs that were not sufficiently mature at the time of the proposed rule to propose to require.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter encouraged CMS to take on an active role in the continued development and testing of the HL7 Da Vinci IGs. The commenter recommended that CMS review and release a formal assessment of the technology development no later than July 1, 2024.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are a member of HL7 and monitor their activities by attending the HL7 Da Vinci workgroups, providing contract support for the development of the IGs, and tracking the ballot process. Through these efforts, we are continuously engaged in IG development and maintenance. We thank commenters for their suggestion but note that the request to release a formal assessment of technology development no later than July 1, 2024, is out of scope for this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters urged CMS to identify a baseline or “floor” version of the technical standards and IGs, and multiple other commenters recommended CMS develop a formal standards advancement process, like the SVAP, to give industry the opportunity to continue refining, testing, and deploying new versions. Multiple commenters noted that requiring an updated version of an IG as a baseline requirement must be done officially through government regulation. Another commenter recommended CMS develop a strategy or a process to decide which version of IGs or standards should be required. A commenter believed that all interested parties should agree upon IGs for each of the APIs. The commenter stated that in the final rule, CMS should identify the requirements, including IGs, for all interested parties. Another commenter recommended that CMS explain the functionalities of specific 
                        <PRTPAGE P="8940"/>
                        IGs they would like applied to each of the APIs.
                    </P>
                    <P>Multiple commenters urged CMS to work with interested parties to identify a limited number of IGs to require so industry is not overwhelmed with too many IGs. Moreover, multiple commenters expressed concern about requiring more than one IG for specific API implementations and requested that CMS only require one IG. A commenter noted they support clear and unambiguous standards to achieve true interoperability.</P>
                    <P>
                        <E T="03">Response:</E>
                         The required standards and recommended IGs for each of the APIs are listed in Table H3 and represent the minimum expected of impacted payers. The FHIR IGs have been developed to fulfill a specific purpose and therefore requiring more than one IG for a specific API is appropriate. Specifically, the IGs we are recommending all have individual purposes and we are only recommending those relevant to each API as listed in Table H3. We also remind interested parties that the IGs go through a consensus-based process and participation in the online meetings and providing feedback is free, thus, we encourage as many organizations as possible with an investment in the development and quality of these guides to participate.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS explain how technical standards and IGs will be mapped to specific API functionalities.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We refer readers to Table H3 for an outline of which standards and IGs pertain to which APIs. We also remind readers that our recommended IGs can support the required standards for the specific API we are recommending them for.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters expressed support for work done by the CARIN Alliance, which provides a method for all payers to make submitted and processed claims data available to patients and has sufficient maturity to ensure a successful implementation. Multiple commenters requested that CMS consider mandating the CARIN IG for Blue Button. A commenter stated that otherwise, stakeholders will have to support multiple IGs, which adds burden and increases technology complexity making development and implementation challenging. Multiple commenters expressed support for clear and unambiguous standards.
                    </P>
                    <P>A commenter stated the CARIN IG for Blue Button already produces an EOB for in-patient, out-patient, professional, pharmacy, dental, and vision services through a set of FHIR profiles. The commenter noted that these same profiles could provide the required non-financial view of the EOBs to meet the requirements outlined in this proposed rule by using the “Summary View” returned by FHIR's summary parameter search.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree about the importance of the CARIN Alliance's work. However, for reasons explained in section II.G.3.a. of this final rule, we did not propose to require several IGs which are listed in Table H3 as Recommended IGs, including the CARIN IG for Blue Button. Regarding the recommendation to leverage the non-financial view of a CARIN IG for Blue Button, we note that in order to do this, the CARIN IG for Blue Button would need to be updated, or other guidance provided to support this requirement, and that the data be made available through the appropriate API. Work is currently underway in CARIN and in coordination with HL7 Da Vinci PDex workgroup to define this guidance.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that a September 2021 Frequently Asked Questions (FAQ) 
                        <SU>187</SU>
                        <FTREF/>
                         document published by CMS states that payers would be compliant with the Patient Access API requirements if they used the CMS-recommended IG (CARIN for Blue Button IG v1.1.0: STU 1) to build their APIs, but that that IG version does not enable the inclusion of dental or vision claims, which were added in the most recent version. Multiple commenters supported guidance or rulemaking to support oral and vision claims using the CARIN IG for Blue Button v2.0.0: STU 2 version.
                    </P>
                    <FTNT>
                        <P>
                            <SU>187</SU>
                             Health Informatics and Interoperability Group (2021). Patient Access API FAQ. Retrieved from 
                            <E T="03">https://www.cms.gov/priorities/key-initiatives/burden-reduction/faqs/patient-access-api</E>
                            .
                        </P>
                    </FTNT>
                    <P>A commenter recommended that CMS reaffirm that impacted payers would be compliant with the requirements for the Patient Access and Provider Access, and Payer-to-Payer APIs if they follow the CMS recommended IGs. The commenter also recommended that CMS further explain that the absence of dental and vision claims information in the proposed APIs would not result in payer noncompliance given that the recommended CARIN IG for Blue Button does not include dental and vision claims.</P>
                    <P>
                        <E T="03">Response:</E>
                         At the time the proposed rule was drafted, the CARIN IG for Blue Button v1.1.0: STU 1 was the latest published version for use. Since then, CARIN IG for Blue Button v2.0.0: STU 2 was released, which indeed includes dental and vision (vision as part of the professional and non-clinician profile). We are therefore modifying our recommendation listed in Table H3 to “HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button) IG v2.0.0: STU 2.” In addition to the required standards listed in Table H3, if impacted payers use the recommended IGs also listed in Table H3 for the APIs and follow the IGs to specification to build their APIs, they would be conformant with the technical requirements.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed support for exchanging data via FHIR APIs and noted that the PDex IG STU 2.0.0 includes a prior authorization profile to share prior authorization information, but this profile is not yet published. However, another commenter noted that the HL7 Da Vinci PDex workgroup is actively completing an initial set of updates to the PDex IG to facilitate sharing prior authorization information and that the workgroup will make any necessary revisions to support the provisions outlined in the proposed rule to include any related administrative and clinical documentation. Another commenter was concerned that some of the proposed data elements for prior authorization have not yet been profiled within FHIR IGs.
                    </P>
                    <P>A commenter stated that payers should already have familiarity with the PDex IG as it was recommended as part of the Patient Access API. The commenter continued that using the PDex IG to support the new set of information will also reduce burden.</P>
                    <P>
                        <E T="03">Response:</E>
                         The recently published PDex IG STU 2.0.0 specification 
                        <SU>188</SU>
                        <FTREF/>
                         does include a Prior Authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. Based on feedback and developments in the industry, in addition to the required IGs and previously recommended IGs, we are now recommending the PDex IG STU 2.0.0. for the Patient Access, Provider Access, and Payer-to-Payer APIs, as listed in Table H3. We are delaying the compliance dates for the APIs finalized in this rule to 2027, which allows for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>188</SU>
                             Health Level Seven International (2020). Da Vinci Payer Data Exchange. Retrieved from 
                            <E T="03">http://hl7.org/fhir/us/davinci-pdex/STU1/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that the proposed rule suggested that the Provider Directory API finalized in the CMS Interoperability and Patient Access final rule will be conformant with the PDex Plan Net IG STU 1.1.0. A commenter stated their belief in 
                        <PRTPAGE P="8941"/>
                        standards-based methods for the electronic transmission of health information. The commenter continued that successful standards-based conveyance of digital health care information relies on clear and unambiguous standards that apply across the industry. The commenter stated that the PDex Plan Net IG meets this requirement.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters on the utility of the PDex Plan Net IG, and are thus recommending its use for the Provider Directory API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended CMS and HL7 ensure the CRD, DTR, and PAS IGs are fully tested prior to the effective date of the final rule, as the IGs have not been adequately or widely tested in real-time clinical settings. A commenter expressed concern with required versus situational data elements in the current versions of the recommended IGs outlined in the proposed rule. The commenter noted that the CRD, DTR, and PAS IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter provided the example that the CRD IG does not require the return of documentation templates and rules, so the provider would be required to initiate a separate transaction to determine the requirements for a prior authorization. Additionally, this commenter stated that the CRD IG allows for hyperlinks to be returned to the provider. The commenter stated that this means that a valid response to a coverage requirements discovery request can be a hyperlink to a third-party prior authorization vendor where the provider would have to initiate a prior authorization request through a provider portal and drop to a manual process outside of their EHR and practice management system.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The HL7 Da Vinci IGs that we recommend specifically for the Prior Authorization API are the CRD, DTR, and PAS IGs. These were created as three distinct IGs that were loosely coupled instead of created as a single IG in order to provide implementation flexibility and the ability to disconnect the processes where necessary. A number of optional or “situational” elements are included in these guides to connect them into a single workflow where needed. While we value the specificity of other comments regarding the functions of the IGs, such as hyperlinks and connecting to external portals, these are the purview of the HL7 Implementation division. We will work with HL7 and implementers to coordinate appropriate support for such questions prior to the compliance dates.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that it was their understanding that the HL7 Da Vinci PCDE IG was developed with minimal payer input. The commenter stated that there may be a need for additional time for impacted payers to understand and implement the IG. Furthermore, the commenter expressed concern that the PCDE IG only addresses the movement of data between the provider and payer and does not address the back-end systems that will need to ingest and process new information for continuity of care. The commenter urged CMS to continue exploring other opportunities to promote data exchange. The commenter acknowledged that there are many industry solutions being developed to facilitate the coordination of benefits between providers. The commenter stated that these options could prove to be better solutions for the industry in the future and recommended that CMS continue to monitor and enable technical innovation in this area.
                    </P>
                    <P>A commenter noted that CMS has included two mentions of the PCDE IG. They stated that there is one reference in the preamble of the proposed rule (87 FR 76336); however, in the preamble “Payer Coverage Decision Exchange” is followed by a parenthetical reference to “PDex.” The commenter stated that the PCDE IG was also listed in Table 10 (87 FR 76321), though, there are no additional or substantive mentions of the PCDE IG in the proposed rule. The commenter believes that it is possible the mention of the PCDE IG was unintentional.</P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge that the PDex IG has expanded to include prior authorization data and development of PCDE IG is not currently active. Thus, while we acknowledge the drafting error the commenter previously noted, we are no longer recommending the PCDE IG for the Payer-to-Payer API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter suggested that CMS consider recommending the HL7® FHIR® Member Attribution (ATR) List IG, which is currently in the publication process. The commenter stated this IG focuses on attribution lists for risk-based contracts and it could serve as an exchange standard for all payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we did not include the ATR List IG as one of recommendations listed in Table H3, we note that industry expects that the next version will be published well before the compliance dates for API development and enhancement policies in this final rule. Payers are permitted to use the ATR List IG, and we will explore including it, either as a recommendation or requirement, in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters recommended that CMS consider leveraging the HL7 FHIR Da Vinci Reducing Clinician Burden (RCB) IGs. A commenter shared that revisions to the RCB IGs are underway to make prior authorization documentation supporting medical necessity, which is assembled by the ordering provider, available to the performing provider. The updated IG is currently titled FHIR Orders Exchange (FOE), and updates should be balloted in the September 2023 SVAP cycle. Another commenter stated that they believe RCB IGs would help industry work towards future readiness for a certified Health IT Module(s) to be included within the ONC Health IT Certification Program.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their suggestions and will consider them for future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG would enable providers to obtain additional information that may have been missing or not yet available on the initial order request.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Though we neither proposed nor recommended the CDex IG, we recognize that the CDex IG is being developed to exchange attachments via the Prior Authorization API. Impacted payers are permitted to use the CDex IG and are encouraged to participate in the ongoing testing as the IG is further developed. Though HL7 has included the ability to exchange attachments in its suite of IGs, and this would be available for use voluntarily, this final rule does not address health care attachments. We will consider either requiring or recommending the CDex IG in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter recommended using the HL7 Da Vinci DTR IG to specify how payers codify their rules in clinical quality language for real-time determination.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We are currently recommending the DTR IG for the Prior Authorization API. We will continue to monitor and evaluate the development of the recommended IGs listed in Table H3 and consider whether to propose them as a requirement at some future date.
                    </P>
                    <HD SOURCE="HD3">c. Authentication and Authorization</HD>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters encouraged CMS to work with HL7 to integrate the UDAP into the IGs created by HL7. A commenter stated that a security framework based on a tiered OAuth security specification is required 
                        <PRTPAGE P="8942"/>
                        to enable the scalable exchange within trust frameworks. The commenter stated that industry will not be able to implement at scale based on how the standards were proposed and suggested CMS focus on making sure this work is in place prior to making the APIs in the proposed rule mandatory. In addition, the commenter stated that the HL7 Da Vinci PDex IG depends on mTLS to establish the identity of each of the organizations involved in the exchange while other payer-to-provider and payer-to-patient exchanges rely on OAuth and the SMART framework.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenters for their responses and understand their concerns. As discussed in section II.B. of this final rule, we are currently supporting efforts to define the specifications for authentication at scale through UDAP via the FAST Security IG and mTLS through the PDex IG.
                    </P>
                    <P>We acknowledge that authentication and authorization via user credentials, using means such as OpenID Connect Core and OAuth 2.0, is a requirement for APIs in which individually identifiable user access is necessary, such as the Patient Access API. In order to use OpenID Connect Core, each user would need to have credentials with the payer (or delegated authentication/authorization entity) to access the API. Thus, we are maintaining OpenID Connect Core 1.0 as a required standard for the Patient Access API.</P>
                    <P>We recognize that while protocols involving specific user credentials as managed by a payer could be used for the Provider Access and Prior Authorization APIs, other protocols, such as SMART Backend Services, mTLS, UDAP, or other trust community-specified means, may be easier to implement at scale. Likewise, protocols requiring user level credentials, managed by the payer, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where an individual may not be directly initiating the exchange. Therefore, upon further consideration of our proposals, we are not finalizing OpenID Connect Core (at 45 CFR 170.215(b)) as either a required or recommended standard for the Provider Access, Payer-to-Payer, and Prior Authorization APIs.</P>
                    <P>We are recommending SMART Backend Services Authorization for both the Provider Access and the Payer-to-Payer APIs. However, payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet appropriate security and privacy requirements. We acknowledge that payers will likely use different protocols, which could represent a barrier to enabling data exchange at scale. Specifications such as UDAP and the tiered OAuth profile is an available option for payers and may enable data exchange in a scalable way by providing dynamic client registration and delegated authentication potentially within and across trust communities. We appreciate the comments, will continue to monitor the progress of UDAP development and implementation, and will consider including it in future rulemaking.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated that the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG Coverage Profile allows for UDAP, which may be viable solution for authentication. The commenter stated that the HL7 FAST STU 1 Security IG should be considered foundational in the future for all IGs that require registration, authentication, and authorization. Additionally, the commenter suggested that CMS should explain that requiring handwritten signatures continues to be appropriate when the impacted payer deems it necessary. The commenter recommended that CMS should support industry discussions and actions toward UDAP alignment across IGs, when and where appropriate.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We recognize that methods including, but not limited to UDAP, may be appropriate depending on the payer's specific needs and the API. We believe that appropriate security controls can be implemented without requiring handwritten signatures, unless required by other applicable law. We continue to monitor the progress of IG development and remind readers that this final rule does not restrict payers from using other IGs (assuming they are not an earlier version than we specify). We will continue to monitor IG development and consider requiring or recommending additional IGs in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">4. Required Standards and Recommended Implementation Guides To Support APIs</HD>
                    <P>Using standards and IGs supports consistent implementations across the industry. In Table H1 of this final rule, we list the CFR citations that require impacted payers to use API technology conformant with the standards and specifications outlined in this section of the rule. We also include Table H3 to provide a clear outline of which standards we require and which IGs we recommend for each API.</P>
                    <BILCOD>BILLING CODE 4150-01-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8943"/>
                        <GID>ER08FE24.011</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8944"/>
                        <GID>ER08FE24.012</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="634">
                        <PRTPAGE P="8945"/>
                        <GID>ER08FE24.013</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-01-C</BILCOD>
                    <PRTPAGE P="8946"/>
                    <HD SOURCE="HD3">5. Final Action</HD>
                    <P>After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238) and our response to those comments (as summarized previously), we are finalizing our proposals regarding interoperability standards for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs.</P>
                    <P>We are finalizing greater specificity for the standards at 45 CFR 170.215 that are applicable to each API, with some modifications. Specifically, impacted payers will only be required to use the applicable standards and specifications that we have identified as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. Those standards are listed as “required” in Table H3. We are also finalizing a modification to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1) since the CMS Interoperability and Prior Authorization proposed rule was published.</P>
                    <P>
                        We are finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs, under the following conditions: the updated version of the standard is required by other applicable law; or (1) the updated version of the standard is not prohibited under other applicable law, (2) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, and (3) the updated version does not disrupt an end user's ability to access the data required to be available through the API. We note that for the required standards at 45 CFR 170.215, several updated versions have been approved by the National Coordinator for use in the ONC Health IT Certification Program,
                        <SU>189</SU>
                        <FTREF/>
                         including, but not limited to, the US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG (v2.0.0: STU 2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>189</SU>
                             Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap</E>
                            .
                        </P>
                    </FTNT>
                    <P>Finally, we are recommending specific IGs, listed as “recommended” in Table H3, which we encourage payers to use in addition to the required standards at 45 CFR 170.215.</P>
                    <HD SOURCE="HD1">III. Collection of Information Requirements</HD>
                    <P>
                        Under the Paperwork Reduction Act (PRA) of 1995, we are required to provide 60-day notice in the 
                        <E T="04">Federal Register</E>
                         and solicit public comment before a collection of information requirement is submitted to the OMB for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA of 1995 requires that we solicit comment on the following issues:
                    </P>
                    <P>• The need for information collection and its usefulness in carrying out the proper functions of our agency.</P>
                    <P>• The accuracy of our estimate of the information collection burden.</P>
                    <P>• The quality, utility, and clarity of the information to be collected.</P>
                    <P>• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.</P>
                    <P>We requested public comment on areas of this document that contain information collection requirements (ICRs).</P>
                    <HD SOURCE="HD2">A. Background</HD>
                    <P>Payers and providers should be able to take advantage of new technologies that improve their ability to exchange information efficiently, enhance operations, and streamline processes to benefit patient care. Payers should share prior authorization rules in more transparent ways to enable providers to meet their requirements, and thereby, avoid care delays. To continue advancements in our commitment to interoperability, we are finalizing our proposals for certain impacted payers to implement FHIR APIs and make other process improvements to help streamline prior authorizations and improve data exchange between payers, providers, and patients. Impacted payers will be required to report metrics for the information about how often patients use the Patient Access API and about prior authorization processes to assess implementation of our policies. The final rule includes provisions that will reduce the amount of time to process prior authorization requests and improvements for communications about denied prior authorizations. Combined, these provisions should reduce the burden on providers, payers, and patients and enhance patient care coordination.</P>
                    <P>To incentivize provider use of the Prior Authorization API, we are finalizing a policy to add a new measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. Beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), we are finalizing this measure as an attestation (yes/no response); we intend to propose a scoring methodology for the measure in future rulemaking. This new measure will be included in a PRA package related to this final rule.</P>
                    <HD SOURCE="HD2">B. Wage Estimates</HD>
                    <P>
                        To derive average costs, we used data from the U.S. Bureau of Labor (BLS) Statistics' National Occupational Employment and Wage Estimates 
                        <SU>190</SU>
                        <FTREF/>
                         and aligned our analysis with other CMS regulatory actions. Table J1 presents the mean hourly wage, the cost of fringe benefits and overhead (calculated at 100 percent of salary), and the adjusted hourly wage.
                    </P>
                    <FTNT>
                        <P>
                            <SU>190</SU>
                             U.S. Bureau of Labor Statistics (2021, March 31). May 2020 National Occupational Employment and Wage Estimates. Retrieved from 
                            <E T="03">https://www.bls.gov/oes/2020/may/oes_nat.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="231">
                        <PRTPAGE P="8947"/>
                        <GID>ER08FE24.014</GID>
                    </GPH>
                    <P>We adjusted the employee hourly wage estimates by a factor of 100 percent or doubling of the BLS wage estimates. This is a rough adjustment because fringe benefits and overhead costs vary significantly across employers based on the age of employees, location, years of employment, education, vocations, and other factors.</P>
                    <HD SOURCE="HD2">C. Information Collection Requirements</HD>
                    <P>Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determined ICRs by evaluating cost and burden at the impacted payer level. We determined that 365 impacted payers together represent the possible plans, entities, issuers, and state programs impacted by these proposals. The increase in impacted payers from the first CMS Interoperability and Patient Access final rule (85 FR 25510) corresponds to the average annual increase in impacted payers for new market entries. The total estimated burden on these impacted payers is described in detail in the following ICRs and Table J9 at the end of this section. We estimated the total number of burden hours across all impacted payers in the first year of implementation at 6.9 million hours; assuming a total cost to impacted payers to begin at approximately $182 million in the first and second years, increasing to $199 million in the third year and decreasing to $142 million by the fourth and subsequent years.</P>
                    <P>We requested comments on each ICR described in the proposed rule (87 FR 76330), and on the assumptions made in deriving these burden estimates. We received a few comments on the burden of the proposals and acknowledge those comments with responses later in this section. Since we did not receive specific data to include to modify estimates, no revisions have been made.</P>
                    <HD SOURCE="HD3">1. Information Collection Requirements Regarding Reporting of Patient Access API Metrics to the Centers for Medicare and Medicaid Services (42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221)</HD>
                    <P>CMS does not currently collect data on using the Patient Access API and does not have industry data on the extent to which patients are requesting to download their data from their payer into an app. We are finalizing the requirement that impacted payers annually report certain metrics to CMS about usage of the Patient Access API. Specifically, we will collect the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. We estimate that impacted payers will conduct two major work phases: (1) implementation, which includes defining requirements and system design to generate and compile reports; and (2) maintenance, which we define as including the compilation and transmission of annual reports to CMS. During the implementation phase, impacted payers will need to prepare their systems to capture the data to be transmitted to CMS.</P>
                    <P>The burden estimate related to the requirements reflects the time and effort needed to identify, collect, and disclose the information. The costs include an initial set of one-time costs associated with implementing the reporting infrastructure and ongoing annual maintenance costs to report after the reporting infrastructure has been established.</P>
                    <P>Table J2 includes our computational estimates for first-year implementation and ongoing maintenance costs and was used to develop the official statement of burden found in Table J9. In finalizing these calculations, we assumed a two-person team of software/web developers and a business operations specialist spending an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) of $15,000 and $3,000. The aggregate burden (rounded) for 365 impacted payers will be 60,000 hours and 15,000 hours for the first and subsequent years at a cost of $5.5 million and $1 million.</P>
                    <GPH SPAN="3" DEEP="132">
                        <PRTPAGE P="8948"/>
                        <GID>ER08FE24.015</GID>
                    </GPH>
                    <P>
                        We did not receive comments specific to the estimates for the Patient Access API metrics reporting.
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>191</SU>
                             U.S. Bureau of Labor Statistics (2021, March 31). May 2020 National Occupational Employment and Wage Estimates. Retrieved from 
                            <E T="03">https://www.bls.gov/oes/2020/may/oes_nat.htm.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Information Collection Requirements Regarding the Provider Access API (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221)</HD>
                    <P>
                        Research shows that patients achieve better outcomes when their medical records are more complete and there are more data available to the health care provider at the point of care.
                        <SU>192</SU>
                        <FTREF/>
                         Making comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data could also reduce the burden on patients to recall and relay information during an appointment and provide confirmation that the patient's recollection of prior care is accurate. This has not always been possible in a disconnected health care system. However, interoperable standards and technology now make it possible for providers to access more patient data for a more comprehensive view of their patients' health history and status. We are finalizing the Provider Access API requirements as described in section II.B.2. of this final rule which permits providers to receive standardized patient data to coordinate care. Cost estimates for this API were developed based on the methodology finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). In that rule, we estimated that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance (85 FR 25605). In this final rule, we assume the same major phases of work will take place for each of the new APIs, with a different level of effort during each work phase.
                    </P>
                    <FTNT>
                        <P>
                            <SU>192</SU>
                             Office of the National Coordinator for Health Information Technology (2019, June 4). Improved Diagnostics &amp; Patient Outcomes. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.</E>
                        </P>
                    </FTNT>
                    <P>In the initial design phase, tasks include determining available resources (for example, personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted resources to facilitate an API connection, convening a team to scope, build, test, and maintain the API, gap analysis, and gap mitigation. During the development and testing phase, impacted payers will conduct mapping of existing data to the FHIR standards, hardware allocation for the necessary environments (development, testing, production), building a new FHIR-based server or leveraging existing FHIR servers, determining the frequency and method by which internal data are populated on the FHIR server, building connections between the databases and the FHIR server, performing capability and security testing, and vetting provider requests.</P>
                    <P>Table J3 summarizes the aggregate burden for complying with the Provider Access API requirements. We provide illustrative points to explain the calculations within the table and the terms used for the headings. The occupational categories on the left side of the table include the titles of the types of labor categories who will perform the work, for example, Database Administrators and Architects, Engineers, and Computer System Analysts.</P>
                    <P>On the top row, under the label “Database Administrators,” the labor cost of $97.20 per hour was obtained from the BLS. The $97.20 represents the mean wage for this occupational title. The calculations in Table J3 reflect time over the period of the project. We estimate that a Database Administrator might spend 480 hours in total to complete this task. The 480 hours are found in the column titled “Primary Hours.” The word primary, as used in the CMS Interoperability and Patient Access final rule (85 FR 25510), refers to the amount of time most organizations would require for this work. The total cost of $46,656 for each organization is obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the column labeled “Total Cost, Primary.”</P>
                    <P>We provide low and high estimates representing a range of possible time and costs across all organizations. The low estimate is half the primary estimate, which is 240 hours. The high estimate is 720 hours. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are obtained by multiplying the low and high estimates of hours by the $97.20 per hour wage. This is a reasonable range that captures the amount of time and cost all organizations may spend on completing this work.</P>
                    <P>The explanation provided for the top row applies to each of the ten occupational titles. The sum of the total hours and costs provides a typical organization's total cost. This number is found in the “Totals for a Single Impacted Payer” row. As depicted, the typical organization might take a total of 2,800 hours at a cost of $270,045. We estimate the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this final rule applies: MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.</P>
                    <P>To arrive at the total cost of the final rule, we multiplied the single organization cost by 365 payers—that is, the number of organizations hosting plans across the programs. For example, the total primary hourly burden of the rule is 1,022,000 (365 organizations × 2,800 for a single organization).</P>
                    <P>
                        Similar to the methodology used in the CMS Interoperability and Patient Access final rule (85 FR 25510), we estimate maintenance costs for future years after the API is established at 25 percent of the aggregate cost. We arrived 
                        <PRTPAGE P="8949"/>
                        at 25 percent based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is estimated to be 25 percent of the cost. For example, the primary aggregate burden over all 365 organizations is $98.6 million, implying that the annual maintenance costs are expected to be $24.6 million (25 percent × $98.6 million).
                    </P>
                    <GPH SPAN="3" DEEP="200">
                        <GID>ER08FE24.016</GID>
                    </GPH>
                    <P>Although compliance with this provision will be required on January 1, 2027, we believe it is reasonable to assume that this API will have to be under development before this date to conduct testing and ensure compliance. Acknowledging that impacted payers will have varying technological and staffing capabilities, as we did in the first CMS Interoperability and Patient Access final rule (85 FR 25606), we are finalizing our estimate that the development of this API will require 1,400 to 4,200 hours of work. We have distributed the cost over 3 calendar years to give impacted payers the flexibility to complete the necessary work (see Table J9).</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters disagreed with CMS's calculations for the total burden regarding hours and costs across all impacted payers and stated that the estimates are significantly understated. These commenters stated that they were not confident that the proposed rule captured the true cost of transitioning to the technical standards.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge comments about our calculations capturing the costs of transitioning to the technical standards, however, the commenters who made these statements did not include any supporting data which we could analyze or include in the final rule. We are aware of and have included available information in our estimates and analysis to address connections, testing, security, and onboarding of third parties, to accommodate the potential costs and burden for each API implementation. Additionally, we believe our estimates are the best possible, without additional information, and reasonable assumptions of staff and time, with ranges to account for low and high costs. We welcome continued input from payers and developers based on implementation of the Patient Access and Provider Directory APIs from the CMS Interoperability and Patient Access final rule, as well as the requirements finalized in this final rule. Such information will also be informative for purposes of future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that it is unrealistic for CMS to expect that the industry can obtain the resources necessary to comply with the provisions outlined in the proposed rule within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates of these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We have acknowledged the constraints on both budget cycles for certain impacted payers such as state Medicaid and CHIP agencies, as well as the technical complexities of implementation, and are finalizing a compliance date in 2027 for policies in this final rule that require API development or enhancement. As explicitly noted previously, the hours of work needed to build the API as indicated in Table J3, acknowledges that impacted payers will have varying technological and staffing capabilities.
                    </P>
                    <HD SOURCE="HD3">a. API Maintenance Costs—All APIs</HD>
                    <P>The third phase for implementation is long-term support and maintenance. Here we discuss our methodology for the development of the costs in aggregate for all APIs outlined in this final rule. As relevant to the APIs discussed in sections III.C.2., 3., and 6. of this final rule, we estimate ongoing maintenance costs for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, in aggregate. The costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. We assume that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would add burden, which would be discussed in future rulemaking. Throughout this section, we discuss the initial design, development, and testing costs per API. This final rule addresses the total maintenance cost for all three APIs.</P>
                    <P>
                        As discussed in the first CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, there will be an annual cost to maintain the FHIR server, including the cost of maintaining the necessary patient data and performing capability and security testing. We believe there are efficiencies to be gained in implementation and maintenance since the APIs rely on several of the same underlying foundational technical 
                        <PRTPAGE P="8950"/>
                        specifications and content. For example, the same standards will be used to implement the new APIs as were used to implement the Patient Access and Provider Directory APIs, including FHIR and complementary security and app registration protocols. We also believe that maintenance costs will be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs in this final rule, as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug fixes, fixed-cost license renewals, contracting costs, and ongoing staff education and training.
                    </P>
                    <P>To account for these maintenance costs, we based our estimates on input from industry experience piloting and testing APIs for provider access, prior authorization, and payer to payer data exchange. We estimated an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs. In Table J9, we account for this maintenance cost separately for each API (at 25 percent of the one-time API cost). As discussed previously, the overlap in some of the recommended IGs across the APIs should result in shared efficiency that we believe supports the assumption that maintenance should be accounted for in aggregate and is presented in this section as such.</P>
                    <P>We requested public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate was reasonable or should be modified, and did not receive specific comments on the aggregate maintenance costs.</P>
                    <HD SOURCE="HD3">3. Information Collection Requirements Regarding the Prior Authorization API (42 CFR 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223)</HD>
                    <P>This API addresses ongoing challenges of the prior authorization process, including identifying whether a prior authorization is required for an item or service; identifying the payer documentation requirements for prior authorization; compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions; and enabling payers to provide a specific response regarding the status of the prior authorization, including information about the reason for denial. We are finalizing the requirement for impacted payers to implement and maintain a Prior Authorization API in this final rule. Use of the Prior Authorization API will begin 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).</P>
                    <P>As discussed previously, with respect to the Provider Access API, we estimate that impacted payers will need to conduct three major work phases to implement the requirements for the Prior Authorization API: initial design, development and testing, and long-term support and maintenance. Furthermore, for the Prior Authorization API, additional tasks are necessary to accomplish the requirements. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all APIs is presented in section III.D. of this final rule.</P>
                    <P>We based our estimate on feedback from industry experts on the anticipated burden of implementing the Prior Authorization API and on current pilots. We continue to believe the estimates to be reasonable regarding the implementation burdens on impacted payers to develop APIs that can facilitate the prior authorization process. In addition to implementing this API, impacted payers will be required to send a specific reason for prior authorization requests that are denied. As discussed in section II.D. of this final rule, while the Prior Authorization API will use the FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 transaction standard and remain HIPAA-compliant. Given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required and licensing costs for accessing the X12 standards in developing the burden estimates. The recommended HL7 IGs are freely available, as HL7 provides access to all IGs as open-source materials. This makes the HL7 standards, IGs, reference implementations, and test scripts available free of charge to the health care and developer community but requires usage and possibly transaction costs for the X12 standards. We have accounted for the necessary engineers, subject matter experts, and health informaticists in our estimates. These personnel resources will need to convert payers' prior authorization rules into computable, structured formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that can interface with the provider's EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the Prior Authorization API with external systems or servers.</P>
                    <P>Though this provision will be effective on January 1, 2027, this API will be under development before that date. Acknowledging that impacted payers have varying technological and staffing capabilities, we estimate that the development of the API will require 5,440 to 16,320 hours of work. In Table J9, we have distributed the cost over approximately 3 calendar years to give impacted payers the flexibility to complete the necessary work.</P>
                    <P>Table J4 presents total burden estimates for the Prior Authorization API (initial design, followed by development and testing). This table presents the calculations associated with the total costs. The numbers from this table are used in Table J9 to present costs per year for 3 years. Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule (85 FR 25510), we used the medium estimate as the primary estimate.</P>
                    <P>The narrative description provided for Table J3 also applies to Table J4. Both tables estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by analyzing costs for a single payer using a team spanning approximately ten occupational titles.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8951"/>
                        <GID>ER08FE24.017</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <P>
                        We requested public comment on our approach and assumptions for the implementation cost of the Prior Authorization API, including whether 
                        <PRTPAGE P="8952"/>
                        our estimates and ranges are reasonable or should be modified. We did not receive any comments on this section.
                    </P>
                    <HD SOURCE="HD3">4. Information Collection Requirements Regarding Requirements To Send Prior Authorization Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230)</HD>
                    <P>Patients need to have timely access to care, and providers need to receive timely responses to their requests for authorization to requests for services for their patients, particularly when waiting for answers can delay the pursuit of alternatives. To increase transparency and reduce burden, we are finalizing our proposal to require that certain impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests. Impacted payers will have to comply with these provisions beginning January 1, 2026. We note that Medicaid managed care plans and CHIP managed care entities will have to comply with these provisions by the rating period beginning on or after January 1, 2026.</P>
                    <P>To implement this policy, there will be up-front costs for impacted payers to update their policies and procedures. We anticipate this burden per payer is 8 hours of work by a general and operations manager to update the policies and procedures, reflecting two half-days of work at a per-entity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a first-year cost of $0.4 million (rounded). These calculations are summarized in Table J5.</P>
                    <GPH SPAN="3" DEEP="90">
                        <GID>ER08FE24.018</GID>
                    </GPH>
                    <P>We requested public comment on our assumptions, estimates, and approach but received no comments on this proposal and therefore are finalizing these estimates without modification.</P>
                    <HD SOURCE="HD3">5. Information Collection Requirements Regarding the Requirement for Public Reporting of Prior Authorization Metrics (42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1230 and 45 CFR 156.223)</HD>
                    <P>To support transparency for patients to understand prior authorization processes, provide some assistance in choosing health coverage, and for providers when selecting or evaluating payer networks we are finalizing our proposal to require that impacted payers publicly report certain prior authorization metrics on their websites. Impacted payers will be required to report aggregated data annually for the previous calendar year's data, beginning March 31, 2026.</P>
                    <P>We estimate that impacted payers will conduct two major work phases: implementation, which includes defining requirements, system design, and updates to generate and compile reports; and maintenance, including an annual compilation of reports and public reporting of metrics on a website. In the first phase, impacted payers will need to define requirements concerning the types and sources of data that need to be compiled regarding prior authorization activities and data, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, impacted payers will need to create the reports and post them to a public web page annually.</P>
                    <P>Table J6 itemizes the activities, hours, and dollar burdens for the first-year implementation and estimated annual maintenance costs. We assumed a team of two staff consisting of a software and web developer with a business operations specialist.</P>
                    <P>• First-year implementation will impose a burden of 320 hours for the first year and 120 hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and subsequent years, respectively.</P>
                    <P>• The aggregate burden of the first-year implementation across 365 impacted payers will be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years.</P>
                    <GPH SPAN="3" DEEP="164">
                        <GID>ER08FE24.019</GID>
                    </GPH>
                    <PRTPAGE P="8953"/>
                    <HD SOURCE="HD3">6. Information Collection Requirements Regarding the Payer-to-Payer API Implementation (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222)</HD>
                    <P>Patients may wish to carry certain health information with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information about their past health history for purposes of managing their care with new or current providers. We are finalizing the requirements for impacted payers to implement and maintain a Payer-to-Payer API as described in section II.C. of this final rule. These provisions will improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. This exchange will be required via a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).</P>
                    <P>As discussed for the other APIs in this rule, impacted payers will conduct three major work phases: initial design, development and testing, and long-term support and maintenance.</P>
                    <P>There will be some costs for impacted payers to implement the Payer-to-Payer API that are unique to this API. There could be costs to test and integrate the Payer-to-Payer API with payer systems, albeit potentially lower costs than those estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the required standards. We accounted for the necessary skill sets of staff required as we also believe there will be unique costs for implementing the PDex IG so that payers can exchange active and pending prior authorization decisions and related documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer.</P>
                    <P>Table J7 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions on the initial design phase and the development and testing phase. Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have the medium estimate as the primary estimate. We provide the following narrative explanation of Table J7:</P>
                    <P>• For the primary estimate, one-time implementation efforts for the first two phases will require, on average, a total of 916 hours per organization at an average cost of $96,072 per organization.</P>
                    <P>• The aggregate burden of the one-time implementation costs across 365 impacted payers will be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the low and high estimates are obtained by multiplying the primary estimate by factors of one-half and one and one-half, respectively.</P>
                    <GPH SPAN="3" DEEP="175">
                        <GID>ER08FE24.020</GID>
                    </GPH>
                    <P>Though this provision will be effective on January 1, 2027, the API will be under development before that date. Acknowledging that impacted payers will have varying technological and staffing capabilities, the development of the API will require 458 to 1,374 hours of work. In Table J9, we have distributed the cost estimates over 3 calendar years to give impacted payers the flexibility to complete the work.</P>
                    <P>We requested public comment on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified, and received none.</P>
                    <HD SOURCE="HD3">7. Information Collection Requirements Regarding the Electronic Prior Authorization Measure for Merit-Based Incentive Payment System and the Medicare Promoting Interoperability Program</HD>
                    <P>The estimates in this section have been submitted to OMB in a PRA package (OMB control number 0938-1278). The burden associated with the proposed requirement for eligible hospitals and CAHs to report the Electronic Prior Authorization measure for the Medicare Promoting Interoperability Program will be captured in the next revision to the PRA package currently approved under OMB control number 0938-1278 (CMS-10552).</P>
                    <P>
                        As explained in section II.F. of this final rule, in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586), commenters indicated that provider reporting would be an appropriate lever by which CMS could encourage using the APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization. Thus, to encourage MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding 
                        <PRTPAGE P="8954"/>
                        API, we proposed to add a new measure, called the Electronic Prior Authorization measure, for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. After consideration of public comments, we have modified the Electronic Prior Authorization measure requirements which are further described and addressed in section II.F. of this final rule.
                    </P>
                    <P>We are finalizing that MIPS eligible clinicians would report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year) and that eligible hospitals and CAHs would report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). For the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs, we are finalizing with a modification that the Electronic Prior Authorization measure be structured as an attestation (yes/no), instead of a numerator and denominator measure as originally proposed for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs are required to report a “yes” or “no” response or report an applicable exclusion, for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points.</P>
                    <P>For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response or claiming an applicable exclusion. A “no” response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined in 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians who do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a “no” response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).</P>
                    <P>For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the minimum program requirements, and therefore would not be considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment.</P>
                    <P>The burden in implementing these requirements consists of reporting an attestation (a “yes” or “no” response) or claiming an exclusion. In the RIA, section IV. of this final rule, we estimate burden based on the effort it takes to report a response for the measure. This estimated burden to report would be the same whether it is to report a “yes or no” response or to report a numerator and denominator as initially proposed. Therefore, modifying the measure to be reported as an attestation does not change the overall cost estimates included in the RIA for this provision. System maintenance is an umbrella term that includes all activities needed to keep a system running. The two main components of system maintenance are preventive and corrective maintenance, which include software tasks such as fixing bugs, updating data sources, deleting old software tasks, adding new tasks, testing, and verification. Maintenance requirements for systems were estimated at 25 percent of total software creation costs, reflecting updates and bug fixes, as well as deletion and creation of software tasks (85 FR 82649). There will be a moderate software update to implement the provisions of this final rule, and there will be no added burden over and above the burden of maintaining already existing software.</P>
                    <P>The data for the reports on prior authorizations and related claims should already be stored in the system software of health care providers who may be required to retain such data for compliance and regulatory reasons. To report the Electronic Prior Authorization attestation (yes/no) measure as specified by CMS, the provisions in this rule should not impose a significant burden of denoting the information in the system.</P>
                    <P>
                        For the added burden of extracting, compiling, reviewing, and submitting the attestation, we assume that for each report, a Medical Records Specialist will spend about half a minute (0.0083 hours) extracting the already-existing data at a cost of $0.39 (1/120 hour (
                        <FR>1/2</FR>
                         minute) × $46.42 per hour). To obtain the aggregate burden, we multiply by the number of entities. This is done separately for eligible hospitals and CAHs, and MIPS eligible clinicians in Table J8.
                    </P>
                    <GPH SPAN="3" DEEP="170">
                        <PRTPAGE P="8955"/>
                        <GID>ER08FE24.021</GID>
                    </GPH>
                    <P>The following items provide support and rationale for the entries in Table J8:</P>
                    <P>
                        • The hourly burden estimates of 
                        <FR>1/2</FR>
                         minute (1/120 = 0.00833 hour) for transmission of the Electronic Prior Authorization attestation (yes/no) response to CMS are consistent with the revised estimates of burden presented in the FY 2024 IPPS/LTCH proposed rule (88 FR 27204). The hourly burden estimates for the Electronic Prior Authorization measure are based on the collection of burden estimates calculated for the Query of Prescription Drug Monitoring Program measure.
                    </P>
                    <P>• The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent with the revised estimates presented in the FY 2024 IPPS/LTCH final rule (88 FR 27205).</P>
                    <P>• The existing MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. As noted in the CY 2024 PFS proposed rule (88 FR 52666), CMS did not propose any submission changes for the MIPS Promoting Interoperability performance category and therefore refers to previous rules for respondent and burden estimates. In Table 132 of the CY 2023 PFS final rule (87 FR 70163), the estimated number of respondents submitting MIPS Promoting Interoperability performance data was based on 2021 participation data collected during the PHE for the COVID-19 pandemic. We anticipate that participation will change over the next 10 years and volumes will rebound to pre-pandemic numbers. We determined that the respondent estimates in Table 122 of the CY 2023 PFS proposed rule (87 FR 46370) are more representational of what we anticipate participation will look like when the Prior Authorization API and associated Electronic Prior Authorization measure provisions are implemented given that these estimates are based on pre-pandemic participation data from CY 2019. Therefore, we maintain that an estimated 54,770 individual or group MIPS eligible clinicians will submit an attestation for the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for the CY 2027 performance period/2029 MIPS payment year. The 54,770 is the sum of the 43,117 individual MIPS eligible clinicians, 11,633 groups, and 20 subgroups estimated to submit MIPS Promoting Interoperability performance data. The ICRs currently approved under OMB control number 0938-1314 are approved through January 31, 2025.</P>
                    <P>• The FY 2024 IPPS/LTCH proposed rule uses mean hourly wage estimates (88 FR 27204), consistent with this final rule and the CMS Interoperability and Patient Access final rule (85 FR 25605). For purposes of clarification, we have provided both mean and median estimates.</P>
                    <P>
                        ++ For eligible hospitals and CAHs, the total cost is $1,741 (4,500 hospitals and CAHs × 
                        <FR>1/2</FR>
                         minute × $46.42 per hour), which equals $0.002 million as shown in Table J9. This rounds to $0.0 million. Calculations using the median instead of the average after rounding are identical. This shows that the bottom-line rounded figure would not change if we used the median instead of the average. The entries in Table J9 are rounded numbers while the actual dollar amounts are provided in Table J8.
                    </P>
                    <P>
                        ++ For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians × 
                        <FR>1/2</FR>
                         minute × $46.42 per hour). Since Table J9 relates to Table K6 in the RIA, we expressed the $21,186 using RIA accounting standards, which require rounding to the nearest tenth of a million. It follows that $21,186 is equivalent to $0.021 million, as shown in Table J9. This value is rounded to $0.0 in the RIA.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter stated the calculation for the aggregate estimates for the Electronic Prior Authorization measure costs is unreasonable and lacks a reasonable basis. This commenter stated there is no way for an employee to run a report in half a minute, as logging into the computer system with two-factor authentication alone can take 1 to 2 minutes. The commenter stated getting to the report in the EHR can take 
                        <FR>1/2</FR>
                         to 1 minute and running a large report can easily take 
                        <FR>1/2</FR>
                         to 2 minutes. The report then needs to be verified and transmitted. The commenter stated instead of half a minute, the process is closer to 5 to 10 minutes. Another commenter stated that the analysis does not account for the payer burden of connecting and testing with all EHRs and practice management systems, specifically the high costs and time commitments. The commenter requested CMS's clarification on whether payers are only required to share with EHR systems certified under the ONC Health IT Certification Program.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate concerns about the timing for reporting but respectfully disagree, particularly because we have modified the reporting specifications for the Electronic Prior Authorization measure. We are finalizing this measure with modifications such that, beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period, a MIPS eligible clinician, eligible hospital, or CAH will report a “yes” or “no” response for the Electronic Prior Authorization measure or claim an exclusion, instead of a numerator and denominator measure as originally proposed. If the MIPS eligible clinician, eligible hospital, or CAH does not report a “yes” response for the Electronic Prior Authorization measure or claim an exclusion, they will receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability 
                        <PRTPAGE P="8956"/>
                        Program, respectively. We are finalizing reporting of the Electronic Prior Authorization measure as an attestation (yes/no) measure beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period. With these modifications, completing and reporting the attestation for the Electronic Prior Authorization measure will not take 10 minutes, but significantly less time to enter into the reporting system. We are explicitly describing time spent reporting the Electronic Prior Authorization measure in this final rule, and half a minute is more representational for reporting a single attestation measure. The entire reporting process for these programs may take longer to complete, for example, 5-to-10 minutes. The amount of time it takes to report data to CMS is dependent on whether the person reporting the data needs to establish their account credentials, the amount of data being reported, and the method through which the data is being submitted. However, this calculation does not intend to calculate the amount of time it takes to conduct the entire process or report all performance data, rather it is solely evaluating the estimated amount of time a person would spend on reporting the Electronic Prior Authorization measure.
                    </P>
                    <P>We also acknowledge this commenter's concern about the basis for the aggregate estimates for the Electronic Prior Authorization measure. However, this commenter did not provide additional data to which we could compare our estimates. Furthermore, we disagree with the commenter as we used information from other interested parties as well as studies to determine that the cost savings will be substantial after a period of years because of the improvements in the prior authorization process for reducing manual effort and delays in services.</P>
                    <P>We did not receive any other comments on this section of the rule. After consideration of public comments, we are finalizing the estimates without modification.</P>
                    <HD SOURCE="HD2">D. Summary of Information Collection Burdens</HD>
                    <P>We have explained the costs of individual provisions in this section. Table J9 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions:</P>
                    <P>• Modified compliance dates for the policies in this final rule that require API development or enhancement, Medicare Promoting Interoperability Program, and MIPS Promoting Interoperability performance category until the CY 2027 performance period/2029 MIPS payment year or CY 2027 EHR reporting period to give 3 years (36 months) for appropriate implementation activities.</P>
                    <P>• Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; these maintenance costs will be incurred in CY 2027 and subsequent years.</P>
                    <P>• Certain provisions will be effective in January 2026; thus, no costs are reflected from 2023 through 2025. However, for the building of the API systems, we assume impacted payers will be performing these updates in CY 2024 through 2026 to be prepared for the CY 2027 compliance date.</P>
                    <P>• Labor costs in Table J9 are either BLS wages when a single staff member is involved or a weighted average representing a team effort, which is obtained by dividing the aggregate cost by the aggregate hours.</P>
                    <P>• Table J9 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this final rule.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="8957"/>
                        <GID>ER08FE24.022</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <PRTPAGE P="8958"/>
                    <HD SOURCE="HD2">E. Conclusion</HD>
                    <P>The provisions of this final rule are expected to improve data sharing across impacted payers and providers by facilitating access, receipt, and exchange of patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We requested comments on our approaches for estimating cost burden and cost savings and received a few comments which have been incorporated herein.</P>
                    <P>The requirements of this final rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the ICRs have been submitted to OMB for review and approval.</P>
                    <HD SOURCE="HD1">IV. Regulatory Impact Analysis</HD>
                    <HD SOURCE="HD2">A. Statement of Need</HD>
                    <P>As described in prior sections of this final rule, the changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS's efforts to empower patients by increasing electronic access to health care data, while keeping that information safe and secure. The provisions in this final rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the health care system toward increased interoperability by enabling better data sharing capabilities of impacted payers, encouraging health care providers' use of new capabilities, and making health-related data more easily available to patients through standards-based technology.</P>
                    <P>The provisions in this final rule place new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to further improve the electronic exchange of health-related data and streamline prior authorization processes. We believe these provisions will improve health information exchange and facilitate appropriate patient, provider, and payer access to health information via APIs, while the policies related to prior authorization should improve certain administrative processes. The final rule also adds a new attestation measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category.</P>
                    <HD SOURCE="HD2">B. Overall Impact</HD>
                    <P>We examined the impacts of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 14094, entitled “Modernizing Regulatory Review” (April 6, 2023), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), Executive Order 13272 on Proper Consideration of Small Entities in Agency Rulemaking (August 13, 2002), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104-4), and Executive Order 13132 on Federalism (August 4, 1999) and the Congressional Review Act (5 U.S.C. 804(2)).</P>
                    <P>Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health, and safety effects, distributive impacts, and equity). Executive Order 14094, entitled “Modernizing Regulatory Review,” amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) having an annual effect on the economy of $200 million or more in any 1 year (adjusted every 3 years by the Administrator of the Office of Information and Regulatory Affairs (OIRA) for changes in gross domestic product), or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, territorial, or tribal governments or communities; (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President's priorities or the principles set forth in this Executive order, as specifically authorized in a timely manner by the Administrator of OIRA in each case.</P>
                    <P>Based on our estimates, OMB's OIRA has determined this rulemaking to be significant per section 3(f)(1) as measured by having an annual effect of $200 million in at least 1 year, and hence is also a major rule under Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (also known as the Congressional Review Act). Accordingly, we have prepared an RIA that, to the best of our ability, presents the costs and benefits of this final rule.</P>
                    <P>These provisions will result in some financial burden for impacted payers and certain providers as discussed in section III. of this final rule. In the proposed rule, we weighed the potential burdens against the potential benefits and believe the benefits outweigh the costs (87 FR 76340). Based on our estimates, the total burden across all providers would be reduced by at least 220 million hours over 10 years, resulting in a total cost savings of at least $16 billion over 10 years as seen in Table K6. We did not include these savings in the 10-year Summary Table (Table K9), nor in the Monetized Table (Table K11), as explained later on in this section of the final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters disagreed with CMS's calculated cost to implement the provisions outlined in the proposed rule and expressed that the actual cost will be much higher than estimated. A commenter stated that they fail to see how the estimated total burden across all providers would be reduced by the proposed rule's estimates of 206 million hours resulting in the total cost saving of $15 billion that CMS asserted in the proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we appreciate that commenters do not concur with the cost estimates, we used the best available data to us at the time we developed the rule and made related assumptions about the reduction in hours for clerical, nursing, and provider staff as a result of the final policies. We are re-stating our assessments of those assumptions and calculations in this final rule. Though commenters and implementers did not submit new data for consideration, we did make a slight revision in the total cost savings to say “at least $16 billion” which includes adjustments of where some of the savings would occur. The potential savings are significant, and we firmly believe that the policies in this final rule will streamline operations, improve efficiencies, and pave the way for substantial changes in the way staff use technology to exchange data and conduct business, particularly for prior authorization. We welcome tangible data from commenters which we could use for comparative analysis of costs and savings.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter raised concerns with the impact analysis and cost calculations CMS included in the proposed rule, taking issue with CMS using data that includes the cost of all prior authorizations, which includes prescription drugs (accounting for 70 percent of prior authorizations), to 
                        <PRTPAGE P="8959"/>
                        calculate the savings potential of the proposed rule, as the policies do not apply to all prior authorizations. The commenter stated that accurate calculations would likely reveal that the rule as proposed is too costly to implement unless CMS modifies it to include prior authorization for prescription drugs, as well as all health plans.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We emphasize that this rule does not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs. We explicitly note that estimates do not include all prior authorizations and that formulary prior authorizations are excluded from our calculation of savings. In addition, this rule does not apply to all health plans and services, but rather to certain impacted payers, including MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We welcome alternative data to support further analysis and will continue to collect information as the final rule is implemented.
                    </P>
                    <HD SOURCE="HD2">C. Regulatory Flexibility Act</HD>
                    <P>Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the RFA). HHS considers a “significant” impact to be 3 to 5 percent or more of the affected entities' costs or revenues. For background on the RFA references in the proposed rule, please see 87 FR 76340.</P>
                    <P>We confirm our analysis of the impacted entities as described in section IV.C. of this final rule.</P>
                    <HD SOURCE="HD3">1. Payers</HD>
                    <P>The 365 payer organizations will perform updates to systems to implement the required APIs and prepare for reporting requirements. As in the proposed rule, we use the term parent organizations in this final rule to refer to the impacted payers (87 FR 76238). The combined parent organizations administer MA plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.</P>
                    <P>The North American Industry Classification System (NAICS) category relevant to these provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which has a $47.0 million threshold for small size. 75 percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses.</P>
                    <P>The 365 parent organizations, including state Medicaid and CHIP agencies, are responsible for implementing and maintaining three new APIs, updating policies and procedures to accommodate revised timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. We determined that state Medicaid and CHIP agencies, as well as many MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are not considered small entities. Furthermore, MA organizations and Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government, and thus we conclude there is no significant burden on small entities in this final rule.</P>
                    <P>We are finalizing the provisions that require API development or enhancement as proposed. We also note that some QHP issuers on the FFEs will be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs will be able to apply for an extension or exemption, under which they will not be required to meet the new provisions of this final rule that require API development or enhancement on the compliance dates, provided certain conditions are met, as discussed in section II.E. further mitigating potential burden for those payers.</P>
                    <HD SOURCE="HD3">a. Medicare Advantage</HD>
                    <P>On an annual basis, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages to CMS. Upon approval, the plan commits to providing the proposed benefits, and CMS commits to paying the plan either the full amount of the bid, if the bid is below the benchmark (a ceiling on bid payments annually calculated from Original Medicare data); or the benchmark amount, if the bid amount is greater than the benchmark. Thus, there is a cost to plans to bid above the benchmark that is not funded by government payments. Additionally, if an MA organization bids above the benchmark for any of its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for that amount. In the proposed rule, we provided a further explanation regarding MA organizations' bids and government payment processes for MA plans and MA plans with prescription drug coverage (MA-PDs) and refer readers to that discussion for additional detail (87 FR 76341).</P>
                    <P>Table K1 reports the percentage of MA organizations bidding above the benchmark, along with the percentage of affected enrollees in recent years. This table reports aggregates of proprietary bid data collected by the Office of the Actuary (OACT). The CMS threshold for what constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As shown in Table K1, both the percentage of plans and the percentage of affected enrollees are below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding above the benchmark is not substantial for purposes of the RFA.</P>
                    <GPH SPAN="3" DEEP="141">
                        <PRTPAGE P="8960"/>
                        <GID>ER08FE24.023</GID>
                    </GPH>
                    <P>The preceding analysis shows that meeting the direct costs of this final rule does not have a significant economic impact on a substantial number of small entities as required by the RFA.</P>
                    <P>There are certain indirect consequences of the final policies, which will also have an economic impact. We explained that at least 98 percent of MA organizations bid below the benchmark. Thus, we estimate that their projected costs for providing services to Medicare beneficiaries for the coming year are fully paid by the Federal Government. However, the government additionally pays the plan a “beneficiary rebate” amount that is an amount equal to a percentage (between 50 and 70 percent, depending on a plan's quality rating) multiplied by the amount by which the benchmark exceeds the bid. The rebate is used to provide additional benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits or to lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be paid by enrollee premiums). If the provisions of this final rule cause the MA organization's bids to increase and if the benchmark remains unchanged or increases by less than the bid does, the result will be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for the health plans' enrollees. However, as noted previously, the number of plans bidding above the benchmark to whom this burden applies does not meet the RFA criteria of a significant number of plans.</P>
                    <P>
                        It is possible that if the provisions of this final rule cause bids to increase, MA organizations will reduce their profit margins, rather than substantially change their benefit packages. This may be in part due to market forces; a plan lowering supplemental benefits even for 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it can be advantageous to the plan to reduce profit margins, rather than reduce supplemental benefits. With this, plans would balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that do not require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit considerations) as temporary because the issuance of a series of regulations sustains the effects.
                        <SU>193</SU>
                        <FTREF/>
                         As a result, changes in benefits packages may be plausible. We did not receive any comments on this section of the RIA regarding small entities, nor on our assumptions about the impact or the general summary of the structure for MA bids. We are therefore finalizing this analysis as is. Based on the previously discussed considerations, the Secretary has certified that this final rule will not have a significant impact on a substantial number of small entities.
                    </P>
                    <FTNT>
                        <P>
                            <SU>193</SU>
                             See similar discussion in previous regulatory analyses: Contract Year 2023 Policy and Technical Changes to the Medicare Advantage and Medicare Prescription Drug Benefit Programs, 87 FR 27704 (May 9, 2022). Retrieved from 
                            <E T="03">https://www.federalregister.gov/d/2022-09375;</E>
                             and Changes to the Medicare Advantage and the Medicare Prescription Drug Benefit Program for Contract Year 2021 and 2022, 87 FR 22290 (April 14, 2022). Retrieved from 
                            <E T="03">https://www.federalregister.gov/d/2022-07642.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Medicaid and CHIP</HD>
                    <P>Title XIX of the Act established the Medicaid program as a Federal-state partnership to provide and finance medical assistance to specified groups of eligible individuals. States claim Federal matching funds quarterly based on their program expenditures. Since states are not small entities under the RFA, we need not discuss the burden imposed on them by this final rule.</P>
                    <P>Medicaid managed care plans and CHIP managed care entities receive 100 percent capitation from the state; we expect that the projected costs associated with the provisions of this final rule will be included in their capitation rates. Consequently, we assert that there will be no substantial impact on a significant number of these entities.</P>
                    <P>As discussed in section II.E. of this final rule for the provisions that require API development or enhancement, states operating Medicaid and CHIP FFS programs may apply for an extension of 1 year to come into compliance with the requirements of this final rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met.</P>
                    <P>Comments pertaining to the Medicaid and CHIP explanation of Federal matching funds are addressed in that section of this final rule, as are those related to the extension and exemption processes.</P>
                    <HD SOURCE="HD3">c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analysis in the SHOP/QHP final rule (78 FR 33233), we estimated that any issuers considered small businesses would likely be subsidiaries of larger issuers that would not be considered small businesses (78 FR 33238), and thus would not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, an exception process is available to QHP issuers on the FFEs, which could further help to address regulatory burden that could otherwise prohibit a QHP issuer from participating in an FFE.</P>
                    <P>
                        We did not receive any comments specific to the QHP summary section of this RFA. Comments related to the 
                        <PRTPAGE P="8961"/>
                        exception process for QHPs are addressed in section II.E.
                    </P>
                    <HD SOURCE="HD3">2. Providers</HD>
                    <P>In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS proposed a new Electronic Prior Authorization measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. CMS proposed that the Electronic Prior Authorization measure would be required for MIPS eligible clinicians beginning with the CY 2026 performance period/2028 MIPS payment year and for eligible hospitals and CAHs beginning with the CY 2026 EHR reporting year. However, after consideration of substantial feedback from commenters described in section II.F. of this final rule, we are finalizing a modification to the Electronic Prior Authorization measure proposal. Rather than requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the Electronic Prior Authorization measure, we are finalizing the measure structured as an attestation (yes/no) measure for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a “yes” or “no” response or report an applicable exclusion for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points.</P>
                    <P>For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response or claiming an applicable exclusion. A “no” response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a “no” response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).</P>
                    <P>For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claim of an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the minimum program requirements, therefore not being considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment.</P>
                    <P>
                        With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden is provided in section III., and supporting data are shown in Table J8. As noted previously, we modified the provision for the Electronic Prior Authorization measure in this final rule based on comments indicating that the denominator calculation would impose a significant burden on providers. We have calculated the burden per individual provider at under $2.50 per year (
                        <FR>1/2</FR>
                         minute of labor times an hourly wage of under $50).
                    </P>
                    <P>Based on all information provided herein, we conclude that the requirements of the RFA have been met by this final rule.</P>
                    <P>We did not receive comments on this subject in the RFA. The modification to the Electronic Prior Authorization measure was not determined to have a significant financial effect on this RIA because there is no need to re-calculate the numerator and denominator and the information will be reported as an attestation. We are finalizing this section as is.</P>
                    <HD SOURCE="HD2">D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements</HD>
                    <P>Section 202 of the UMRA also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2023, that threshold is approximately $177 million. This final rule will not impose an unfunded mandate that results in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $177 million in any 1 year.</P>
                    <P>Executive Order 13132 establishes certain requirements that an agency must meet when it publishes a final rule that imposes substantial direct costs on state and local governments, preempts state law, or otherwise has federalism implications. As previously outlined, while the provisions that require API development or enhancement will be a requirement for state Medicaid and CHIP agencies as described in this final rule, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary. The analysis we conducted did not consider Federal matching funds provided to state Medicaid and CHIP agencies, and the conclusion was the same: there is not expected to be a significant cost impact on state entities.</P>
                    <P>For Medicaid and CHIP, we are unaware of any provisions in this final rule that conflict with state law, and no commenters raised a pre-emption issue other than the timeframe issue discussed later in this section. Therefore, we do not anticipate any preemption of state law. As discussed in section II.D. of this final rule, some state laws regarding timeframes for prior authorization decisions may be different than the provisions in this final rule. However, an impacted payer will be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invited states to comment on the proposed rule if they believed that any proposal in this rule would conflict with state law. We received a few comments from states and other organizations regarding the preemption of state law regarding timeframes and addressed these comments regarding prior authorization decision timeframes and compliance with state law in section II.D. of this final rule.</P>
                    <P>As noted previously in this section, we considered whether the provisions in this final rule imposed substantial costs on state or local governments, preempted state law, or had federalism implications and concluded that the rule does not. Therefore, the requirements of Executive Order 13132 are not applicable.</P>
                    <HD SOURCE="HD2">E. Regulatory Review Costs</HD>
                    <P>
                        If regulations impose administrative costs on private entities, such as the time needed to read and interpret this final rule, we are required to estimate the cost associated with regulatory review. We modeled our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). In the proposed rule, we cited three numbers that were needed to calculate this estimate: (1) number of staff per entity performing the reading; (2) number of hours of reading; and (3) number of entities reviewing the final 
                        <PRTPAGE P="8962"/>
                        rule. We estimated a one-time aggregated total review cost of $1.3 million ($128.71 × 10 hours of reading time × 500 entities × two staff per entity). We requested comments on our estimate and assumptions. However, we did not receive any comments. For further details on this matter, refer to the proposed rule at 87 FR 76343. Therefore, we are finalizing the analysis as presented.
                    </P>
                    <HD SOURCE="HD2">F. Impact of Individual Proposals</HD>
                    <P>The provisions of this final rule all have information collection-related burdens. This information is provided in Table J9 in section III. of this final rule. Table K2 provides a list of the ICRs by number and title, as well as the table numbers in which we provided an impact assessment.</P>
                    <GPH SPAN="3" DEEP="172">
                        <GID>ER08FE24.024</GID>
                    </GPH>
                    <P>Additionally, this RIA section provides an analysis of expected savings to providers arising from the replacement of paper documents related to prior authorization and other plan requirements with EHRs. Although these savings are neither included in the Monetized Table (Table K11) nor in the Summary Table (Table K9), we believe that these large savings are an important consideration in understanding this final rule. We have identified our assumptions for savings at the end of this section.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters sought clarification regarding CMS's analysis of how the proposed rule would impact industry. Commenters stated that the discussion of the costs and benefits of the proposed rule was not specific enough and disagreed with CMS's claim that the benefits of the provisions are greater than the costs. Additionally, a commenter noted that the costs estimated in the proposed rule vastly underestimate the true cost of implementing and complying with the provisions. The commenters provided recommendations on certain concepts and ideas that CMS should take into consideration when assessing the regulatory impact of this rule.
                    </P>
                    <P>A few commenters expressed concerns over the calculations associated with prior authorization. For example, one commenter noted that CMS failed to account for the increase in prior authorization burden since the publication of the Casalino report in 2009. Another commenter noted that CMS failed to include a 2.5 percent fee for electronic prior authorization transactions and the costs healthcare providers expect to incur. A commenter agreed that some upfront costs would be incurred but noted that new burdens and costs would be imposed on payers, which must be considered. Another commenter noted that there is little to no quantitative or qualitative data to justify CMS's approach to calculating cost and savings associated with the provisions in this rule.</P>
                    <P>Several commenters recommended that CMS work with payers and providers to develop protocols to help identify specific cost savings and efficiencies from automating the prior authorization process.</P>
                    <P>
                        <E T="03">Response:</E>
                         CMS bases the impact analysis on data we can obtain from past research and other available information. During development of the proposed rule, we made certain assumptions about implementation and development costs. However, based on the number of pilots in the launch phase, we are optimistic that we will have additional data following implementation. To the extent feasible, we encourage industry to share data with us, which would be subject to all requested confidentiality and proprietary protections afforded under the Freedom of Information Act.
                        <SU>194</SU>
                        <FTREF/>
                         We will look for opportunities to engage with impacted entities to identify both cost savings and expenditures based on automation of prior authorization processes which would support the publication of the findings.
                    </P>
                    <FTNT>
                        <P>
                            <SU>194</SU>
                             Office of Information Policy, U.S. Department of Justice (n.d.). Freedom of Information Act Homepage. Retrieved from 
                            <E T="03">https://www.foia.gov/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that it is unrealistic for CMS to expect that industry can obtain the resources necessary to comply with these policies within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates for these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year. Another commenter recommended that CMS reconsider the proposed timeline of certain provisions in the rule given the critiques on the RIA and consider reshaping this rule into a roadmap with milestones along the journey that would signal that a new requirement was ready for implementation. A commenter recommended that CMS adjust the RIA to account for changes in the FHIR-based standards and recommended IGs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate concerns about implementation costs and timing, as they pertain to this impact analysis, for states which are dependent on state fiscal timelines for approvals and procurements. We also remind readers that some impacted payers may be eligible to apply for extensions, exceptions, and exemptions under certain circumstances, as described in section II.E. of this final rule. We believe that the finalized extensions, 
                        <PRTPAGE P="8963"/>
                        exceptions, and exemptions will adequately address any contingencies faced by individual payers and other affected entities. Finally, as stated in section I.D. of this final rule, we are finalizing compliance dates in 2027 for the policies in this final rule that require API development or enhancement, in recognition of the need for analysis, procurement, training, testing, and development. We appreciate the commenter's feedback on updating our impact analyses to account for changes to the FHIR standards, specifications, and IGs. However, we disagree that updates to standards, specifications, and IGs should be accounted for in the impact analysis. Changes to standards, specifications, and IGs do not have any bearing on the calculation of an impact analysis. We acknowledge that it will be important for implementers to remain engaged in the HL7 workgroups and implementation forums. We are requiring entities to use certain IGs specified in this final rule and the ONC Cures Act final rule (85 FR 25642); those standards will remain consistent. Should there be updates to any of those standards or IGs, changes will be made available to implementers through SVAP, as they are tested and approved by ONC. Industry is strongly encouraged to participate in that process to ensure awareness and readiness, but we do not believe that the changes or process for those changes is of significance for the impact analysis.
                    </P>
                    <P>Finally, as discussed earlier in this final rule, some commenters wrote regarding the potential costs that might be passed on to providers from EHR vendors or payers for use of the APIs, in the form of user fees. We recognize that EHR vendors, providers, and payers have costs of doing business, particularly for the development and implementation of the APIs, as described in this RIA. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers' API endpoints. We did not include information regarding user fees for APIs in this impact analysis because of the lack of available data on the costs incurred between payers, developers, EHRs and providers. However, we are committed to monitoring and evaluating the expanding landscape of API usage and will consider opportunities to provide future guidance on this topic, to ensure that we can provide comprehensive and up-to-date information for our industry partners.</P>
                    <P>The Summary Table (Table K9) of this section, using Table J9 as a basis, provides a 10-year impact estimate. Table K9 includes impact by year, by type (parent organizations, including state Medicaid and CHIP agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to MA organizations, Medicaid, and CHIP, as well as the premium tax credits (PTCs) paid to certain enrollees in the individual market.</P>
                    <HD SOURCE="HD2">G. Alternatives Considered</HD>
                    <P>We stated in the proposed rule that we are continuing to build on the efforts initiated with the CMS Interoperability and Patient Access final rule (85 FR 25510) and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their data. This final rule covers several provisions aimed at achieving these goals. We described alternatives to our proposals in the proposed rule and the reasons we did not select them as proposed provisions. The details for each of those alternatives and the rationale behind not including them are available in the proposed rule at 87 FR 76344.</P>
                    <HD SOURCE="HD3">1. Alternatives Considered for the Patient Access API Enhancements</HD>
                    <P>We are finalizing modifications to our proposals to require payers to make enhancements to the Patient Access API, which was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). We are requiring payers to make additional information available to patients through the Patient Access API and to report certain metrics about patient use of the Patient Access API to CMS annually. We considered several policy alternatives for the Patient Access API. These are described in the proposed rule at 87 FR 76344, and relevant comments regarding the Patient Access API are addressed in section II.A. of this final rule.</P>
                    <P>Regarding reporting Patient Access API metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For example, we considered a quarterly requirement. Public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586) indicated a preference for less frequent reporting to reduce burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goal of understanding patient utilization of the API. Comments regarding reporting on Patient Access API metrics are addressed in section II.A. of this final rule.</P>
                    <P>The quantitative effect of quarterly reporting will likely not change the bottom line of $1.6 billion cost over 10 years shown in Table K9. However, we acknowledge it may change marginally to $1.7 billion. As shown in the various tables of section III. of this final rule, the annual cost of reporting is estimated at $3.2 million based on hours of work required by a business operations specialist. If we required quarterly reporting this would quadruple the estimate or add about $10 million annually—or a little under $100 million over 10 years. This would raise the $1.558 billion cost to at most $1.658 which, when rounded, would be either $1.6 or $1.7 billion.</P>
                    <P>We also considered earlier compliance dates for the proposed enhancements to the Patient Access API. In the proposed rule, we stated it would be more appropriate, and less burdensome on impacted payers to propose compliance dates for these provisions in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), which would have provided a 2-year implementation timeframe. However, based on public comments, we are finalizing a compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) for the policies in this final rule that require API development or enhancement. Additional information regarding the updated compliance dates for the APIs is available in sections I.D., II.A., II.B., II.C., and II.D. of this final rule.</P>
                    <P>
                        Had we implemented the rule a year earlier, the aggregate $1.6 billion over 10 years would change to $1.7 billion over 10 years. The total cost for creating the various APIs would not change; rather, they would be apportioned over 2 years rather than 3 years. However, if we required compliance a year earlier, then the maintenance costs of $142 million per year would begin in year 3 rather than in year 4. This would add an extra $142 million per year of cost raising the aggregate 10-year cost of $1.55 billion to $1.69 billion or $1.7 billion after rounding.
                        <PRTPAGE P="8964"/>
                    </P>
                    <HD SOURCE="HD3">2. Alternatives Considered for the Provider Access API</HD>
                    <P>To better facilitate the coordination of care across the health care continuum, we are finalizing our proposal to require impacted payers to implement and maintain a Provider Access API. This API will require payers to make available to certain providers the same types of data they make available to patients via the enhanced Patient Access API.</P>
                    <P>As noted in the proposed rule at, we considered other data types that could be exchanged via the Provider Access API and considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) (87 FR 76345). While this would have required that less data be exchanged and, thus, be less burdensome for impacted payers to implement, we believed that claims and encounter information would complement the content standard and offer a broader and more holistic understanding of a patient's interactions with the health care system. Furthermore, the data that we proposed to be made available through the Provider Access API aligns with the data that we proposed to be made available to individual patients through the Patient Access API. We also considered including additional data elements as required for the Provider Access API, requiring a complete set of data available from the payer's system. However, we did not receive such suggestions from industry, including patients, and such a large volume of data types might have been overwhelming for providers, would have been an excessive cost, and would likely not have met minimum necessary provisions. A more robust description of the alternatives and our rationale for not selecting those are set out in the proposed rule (87 FR 76346). We did not receive comments specifically on the alternatives considered in this section. Other comments regarding the Provider Access API are addressed in section II.B. of this final rule.</P>
                    <HD SOURCE="HD3">3. Alternatives Considered for the Payer-to-Payer API</HD>
                    <P>We are finalizing our proposal to require impacted payers to implement and maintain a Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This provision will make the same data that is being made available to patients and providers also available to other payers when a patient changes plans. This will allow patients to take their data with them as they move from one payer to another. Before finalizing this provision, we considered several alternative provisions which we described in detail in the proposed rule (87 FR 76346).</P>
                    <P>For example, in the CMS Interoperability and Patient Access final rule, we finalized a policy to require payers to exchange data with other payers but did not require a specific mechanism for the payer to payer data exchange to occur. Rather, we required impacted payers to receive data in whatever format it was sent and accept data in the form and format it was received, which ultimately complicated implementation by requiring payers to accept data in different formats. The cost to implement these various formats cannot be calculated because there are endless possibilities and combinations of ways the data could have been exchanged under the previously finalized policy.</P>
                    <P>Unlike the policy finalized in the CMS Interoperability and Patient Access final rule, the use of an API would reduce the amount of implementation cost needed for this data exchange. Importantly, for the Payer-to-Payer API, once an organization implements the other APIs of this final rule, less additional investment will be necessary to implement the payer to payer data exchange, as payers would be able to leverage the infrastructure already established for the Patient Access and Provider Access APIs. The updated background information for the recommended IGs is found in section II.G. and explains how the existing resources can be tailored to meet the provisions set out in this final rule. Given this available infrastructure and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to implement an API for this enhanced data exchange. We did not receive any comments on this section, but comments specific to the proposal for the Payer-to-Payer API are addressed in section II.C. of this final rule.</P>
                    <HD SOURCE="HD3">4. Alternatives Considered for the Prior Authorization API and Other Prior Authorization Process Requirements</HD>
                    <P>We are finalizing our proposals for several important policies to improve the prior authorization process, which we described in the proposed rule (87 FR 76346). Our final policy to require that all impacted payers implement and maintain a Prior Authorization API will ultimately help patients receive the items and services they need in a timely fashion, and support streamlined communication between providers and payers. The Prior Authorization API aims to improve care coordination by providing more structured information about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. The API will be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standard. The standards and IGs that support the development of this API are already being tested and piloted with some success between providers and payers, and we believe as enhancements to the IGs are made over the next few years, more organizations will see the benefit for their programs.</P>
                    <P>As noted previously, we described our considerations for a phased approach, or partial implementation of the API over time, and explained why we did not propose those options. We did not receive comments in support of a partial implementation in part because of the risk that such an option might result in inconsistent implementations and increase burden for providers. As indicated, though quantitative data from current prior authorization pilots have been shared informally with the public, it has not yet been submitted to CMS for use in official evaluations or analysis. CMS anticipates receipt of the pilot results in CY 2024.</P>
                    <P>Though we do not have specific data, we believe the quantitative effects of a phased in implementation option would be negligible. The total cost of developing the Prior Authorization API would not change; however, such an approach could mean delaying the 25 percent maintenance costs by 1 or 2 years, as well as the overall benefits of the API.</P>
                    <P>We are finalizing our requirement that impacted payers publish certain data about their performance on prior authorization, on a public website, and though we considered options for this reporting, we believe in the first few years of program implementation it will be important to gather feedback from payers, providers and patients as to the usability of the information being made available before modifying the requirement. As explained in section II.D. of this final rule, CMS is committed to working with impacted entities on best practices for reporting.</P>
                    <P>
                        We considered using only the X12 278 transaction standard adopted under HIPAA rather than requiring the implementation of a FHIR API to support the Prior Authorization API. While the adopted X12 278 transaction standard defines the content and format for the exchange of data for prior authorization, it does not have the 
                        <PRTPAGE P="8965"/>
                        functionality of the FHIR standard or IGs to support the requirements of the Prior Authorization API. This includes the ability to accommodate all of a payers' business rules, indicate which supporting documents are required, create a questionnaire, and conduct an end-to-end transaction via FHIR for real-time responses. We received confirmation through many comments that the X12 standard is not designed to enable using SMART on FHIR apps connected to the provider's EHR system, nor is it designed for the scope envisioned in this rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The substantive comments on this subject are addressed in section II.D. of this final rule.
                    </P>
                    <P>We are finalizing the operational, non-technical provisions related to prior authorization processes, including requirements for certain impacted payers to respond to expedited prior authorization requests within 72 hours, and to standard prior authorization requests within 7 calendar days. We received many comments suggesting that the response timeframes be shortened because of the potential impact on patient care, and those comments are addressed in section II.D. of this final rule.</P>
                    <P>Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes outlined in the proposed rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers.</P>
                    <HD SOURCE="HD2">H. Savings Through the Adoption of the Prior Authorization Provisions by Health Care Providers</HD>
                    <HD SOURCE="HD3">1. Overview</HD>
                    <P>As described in section II.D. of this final rule, we have finalized new requirements related to prior authorization for impacted payers, and in section II.F. of this final rule, we described a new Electronic Prior Authorization measure and the associated reporting requirements for MIPS eligible clinicians, eligible hospitals, and CAHs.</P>
                    <P>In section III.C. of this final rule, we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals, and CAHs. Here we address the anticipated cost savings of these provisions for the broader health care provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, eligible hospitals, and CAHs.</P>
                    <P>We believe that all health care providers can benefit from the provisions for impacted payers to implement the APIs in this final rule and base these cost-savings estimates over 10 years. We use the estimated total number of providers, with estimates described in this section of the final rule. To conduct this analysis, we used available resources and invited comments on our assumptions, the data, and our citations.</P>
                    <P>The savings estimated in this final rule are true savings, not transfers, since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings will be an indirect consequence of the final rule, not direct savings. This final rule supports efforts to significantly reduce time spent on manual activities. In general, it is only appropriate to claim that a regulatory provision's benefits are greater than its costs after a substantive and preferably quantitative, assessment of the pre-existing market failure and the provisions' suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included in the Monetized Table (Table K11) nor the Summary Table (Table K9) of this final rule. Nevertheless, the savings could be significant, and we believe should be a factor in the industry's assessment of this final rule. In the proposed rule, we requested comments on how CMS might attribute savings benefits to avoid double-counting, and how CMS could account for both costs and benefits from policy interactions but did not receive specific comments in response.</P>
                    <P>We are only quantifying savings of reduced paperwork for health care providers. However, the improved efficiencies outlined in this rule have potential positive consequences, which could lead to savings. Several surveys by the AMA cited in section II.D. of this final rule, list adverse qualitative consequences of the current paper-based prior authorization system, including life-threatening adverse medical events, missed, or abandoned treatments, hospitalization, and permanent bodily damage, however, we do not have specific data related to outcomes.</P>
                    <HD SOURCE="HD3">2. Methodology for Savings Analysis</HD>
                    <P>The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The provisions of this rule potentially affect individual physicians, physician groups, hospitals, and CAHs. However, for purposes of quantification, we initially estimate a reduced paperwork burden for individual physicians and physician groups, which shows a savings of several billion dollars over 10 years. We base the estimate on the number of hours per week spent on prior authorization, using information about individual physicians and physician groups from survey data we believe to be reliable (three surveys of several thousand groups from 2006, 2021, and 2022 cited in this section of the final rule). To calculate our estimates, we used the same physician information and made certain assumptions of its applicability to hospitals. The purpose of using this comprehensive provider information from three different periods was that no other comprehensive data set was available to identify savings from reduced paperwork. Our initial estimate was for savings of several billion dollars for individual physicians and physician groups.</P>
                    <P>To estimate reductions in spending on paperwork for prior authorization for hospitals, we assumed that hospitals perform similar prior authorization activities to individual physicians and physician groups. We made this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have survey data of similar quality for hospitals on the number of hours per week spent on prior authorization and the proportion of hours per week spent by physicians, nurses, and clerical staff.</P>
                    <P>To support the assumptions on potential benefits for hospital prior authorization, we rely on data from previously published rules. To avoid repetition of numbers and sources we summarize all updates in this final rule, along with the estimates of the proposed rule, subtotals, and sources in Table K3. Throughout this section, numbers without specified sources, come from this table.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="420">
                        <PRTPAGE P="8966"/>
                        <GID>ER08FE24.025</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <P>
                        To calculate the burden and savings for the final rule, we are using the data from the FY 2024 IPPS/LTCH proposed rule (88 FR 27205), FY 2024 OPPS proposed rule (88 FR 49552), and CY 2023 PFS proposed rule (87 FR 46370) rather than the CY 2023 PFS final rule (87 FR 69404) or CY 2024 PFS final rule (88 FR 78818), as these sources more accurately reflect the anticipated number of hospitals and providers impacted by our provisions beginning on January 1, 2027. We believe these sources are more reflective of the eligible hospitals and CAHs who will participate in the Medicare Promoting Interoperability Program and the MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category over time. We elected to use MIPS eligible clinician participation data from the CY 2023 PFS proposed rule, rather than the CY 2023 PFS final rule or CY 2024 PFS final rule, to estimate the number of MIPS eligible clinicians reporting MIPS Promoting Interoperability data to CMS because the 45 percent reduction in the estimated number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data between the CY 2023 PFS proposed rule (based on CY 2019 participation data) and the CY 2023 PFS final rule (based on CY 2021 participation data) appear to be lower due to the effects of the COVID-19 PHE. Likewise, the number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data as estimated in the CY 2024 PFS final rule (based on CY 2022 participation data) remain impacted by the COVID-19 PHE,
                        <SU>195</SU>
                        <FTREF/>
                         which formally ended on May 11, 2023. We do not believe this reduction in MIPS eligible clinicians reporting MIPS Promoting Interoperability data will be persistent and believe it is reasonable that participation numbers in future years may revert to their former levels (before the COVID-19 PHE).
                    </P>
                    <FTNT>
                        <P>
                            <SU>195</SU>
                             U.S. Department of Health and Human Services (2023, May 9). Fact Sheet: End of the COVID-19 Public Health Emergency. Retrieved from 
                            <E T="03">www.hhs.gov. https://www.hhs.gov/about/news/2023/05/09/fact-sheet-end-of-the-covid-19-public-health-emergency.html.</E>
                        </P>
                    </FTNT>
                    <P>Additionally, we modified another assumption for this final rule, acknowledging an increase in hours spent on prior authorization from 13 hours per week spent on prior authorization in 2021 to 14 hours per week spent on prior authorization in 2022. We did so using AMA survey data results which we believe are more reasonable. This change in data encouraged us to update our estimations accordingly.</P>
                    <P>
                        To account for these changes, and to avoid injecting our own subjective 
                        <PRTPAGE P="8967"/>
                        biases on the changes, we have included calculations using both years of the AMA prior authorization survey data. The two total savings estimates are based on the AMA prior authorization survey data, one using 2021 survey data and the other using 2022 survey data, which differed by about 10 percent. Both resulted in estimated savings of several billion dollars over 10 years. The amount and effect of these changes as well as the deviation from the proposed rule estimates are set out below.
                    </P>
                    <P>Additionally, given that estimates for MIPS eligible clinicians reporting MIPS Promoting Interoperability data in the CY 2023 PFS final rule were based on CY 2021 participation data collected during the COVID-19 PHE, we are using data published in the CY 2023 PFS proposed rule as cited in Table K3 for our calculations. We believe that this is reasonable because the MIPS eligible clinician estimates from the CY 2023 PFS proposed rule are based on pre-pandemic participation data from CY 2019. As noted previously, we do not believe the reductions in participation in the MIPS Promoting Interoperability performance category will continue long term. We believe it reasonable to assume that participation numbers will continue to increase, at a minimum, by the compliance dates for the policies that require API development or enhancement (beginning on January 1, 2027).</P>
                    <HD SOURCE="HD3">3. Physicians and Hospitals</HD>
                    <P>The approach presented in the proposed rule, and finalized here, computes aggregate savings for physician or group physician practices by first estimating the savings for a single individual physician or group physician practice based on supporting surveys, and then multiplying this single savings by the number of practices. Using the updated numbers from Table K3 results in savings of at least $15.8 billion over 10 years for individual and physician groups.</P>
                    <P>We assume hospitals are conducting the prior authorization process in a manner similar to physicians. Thus, the individual physician and group physician practices would save at least $15.8 billion over 10 years, as shown in Table K6, and the combined physician practices and hospitals (207,515 practices consisting of 199,543 individual physician and group physician practices plus 7,972 hospitals and CAHs) would save at least $16.5 billion (207,515/199,543 × $15.8 billion). To the nearest billion, both $15.8 and $16.5 round to $16 billion. The numerical savings are the same whether we include or exclude hospitals.</P>
                    <HD SOURCE="HD3">4. Base Estimates of Paperwork Savings to Providers</HD>
                    <P>In calculating the potential savings, uncertainties arise in four areas. The result of this illustrative analysis is that we find a minimal potential savings point estimate of $15 billion (using 2021 AMA prior authorization survey data) and $16 billion (using 2022 AMA prior authorization survey data) over 10 years. To provide credibility to this savings analysis we have, where we lacked better data, underestimated any unknown quantities with minimal estimates and additionally studied the effect of a range of estimates.</P>
                    <P>In the next few paragraphs, we summarize the four uncertainties and indicate how we approached the estimation. We refer readers to a more detailed discussion of these assumptions in the proposed rule (87 FR 76348). We received one comment on the quantitative estimate for providers and have responded to that comment elsewhere in the final rule. However, because no additional data was provided, we are not changing general assumptions in this final rule, except that we are updating numbers based on Table K3.</P>
                    <HD SOURCE="HD3">a. Assumptions on the Relative Proportion of Current Workload Hours and Costs by Staff for Prior Authorization</HD>
                    <P>• For labor costs, we used the mean hourly wages from the BLS.</P>
                    <P>• For total hours spent per week on prior authorization by staff overall we use the latest 2022 AMA survey (Table K3) rather than the estimate used in the proposed rule, which was based on the 2021 AMA prior authorization survey.</P>
                    <P>
                        • For the estimates of the current proportions by the staff of paperwork involved in prior authorization processes, the type of staff involved, and the type of physician offices, we used numbers in a survey presented by Casalino et al. (2009),
                        <SU>196</SU>
                        <FTREF/>
                         which gave a detailed analysis based on a validated survey instrument employed in 2006. By dividing, for each staff type, the total prior authorization time spent per week across all physician practices, over the total prior authorization time spent across all practices and all staff types, we obtained the proportion of time each staff type spent per week on prior authorization. These proportions were applied to the updated total time per week spent on prior authorization as given in Table K3.
                    </P>
                    <FTNT>
                        <P>
                            <SU>196</SU>
                             Casalino, L.P., Nicholson, S., Gans, D., Hammons, T., Morra, D., Karrison, T., &amp; Levinson, W. (May 2009). What Does It Cost Physician Practices to Interact with Health Insurance Plans? Health Affairs, 28(4): w533-w543. doi: 10.1377/hlthaff.28.4.w533.
                        </P>
                    </FTNT>
                    <P>The updated results are presented in Table K4 which shows that individual and group physician practices annually used, on average, at least 728 hours per year at a cost of at least $52,642 on prior authorization.</P>
                    <GPH SPAN="3" DEEP="148">
                        <GID>ER08FE24.026</GID>
                    </GPH>
                    <PRTPAGE P="8968"/>
                    <P>Here, we provide information on the row on registered nurses for demonstration purposes. Registered nurses are estimated to spend at least 9 hours per week on prior authorization, and hence, spend 467.5 hours per year (9 hours per week × 52 weeks per year). By multiplying the 467.5 hours per year spent on prior authorization by the mean wages per hour for registered nurses, $76.94, obtained from the BLS, we obtain an aggregate annual cost of $35,969 for registered nurses dealing with prior authorization. The other rows are interpreted following the same process.</P>
                    <HD SOURCE="HD3">b. Assumptions on the Total Number of Individual and Group Physician Practices</HD>
                    <P>Table K4 presents the current hour and dollar burden for a single physician group and single physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, we use the data in Table K3, which includes a reference to 199,543 total individual and group physician practices. This number is used to inform Table K6 which represents a 10-year summary of annual costs.</P>
                    <HD SOURCE="HD3">c. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the Provisions of This Final Rule</HD>
                    <P>Table K4 provides current hours spent on prior authorizations. To calculate potential savings, we assume how much these hours will be reduced as a result of the provisions of this final rule.</P>
                    <P>A detailed discussion driving our assumptions was presented in the proposed rule (87 FR 76350). Based on the provisions in this final rule, we assume that physicians, nurses, and clerical staff will reduce the time they spend on prior authorization by 10 percent, 50 percent, and 25 percent respectively. Having received no comments on our estimates, we have retained these estimates for purposes of the final calculations. The savings, updated with the numbers from Table K3, is presented in Table K5.</P>
                    <P>The narrative following Table K5 presents the total 10-year savings with different reduction assumptions; however, these different reduction assumptions do not materially change the range of estimates.</P>
                    <GPH SPAN="3" DEEP="162">
                        <GID>ER08FE24.027</GID>
                    </GPH>
                    <P>To provide an explanation of Table K4, we use registered nurses as an example. registered nurses spend 467.5 hours per year on prior authorization (see Table K3). If we assume that registered nurses, as a result of the finalized provisions of this rule, reduce the number of hours per week by 50 percent (about half a day, or 4 hours, per week) then they would save 233.7 hours per year (50 percent × 467.5 hours). Multiplying the hours saved, 233.7 hours, by the mean hourly wage for registered nurses, $76.94, the annual aggregate savings per physician practice is $17,984. The other rows may be interpreted similarly.</P>
                    <HD SOURCE="HD3">d. Assumptions on the Number of Individual and Group Physician Practices Adopting the Provisions of This Final Rule</HD>
                    <P>As in the proposed rule, we are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the provisions outlined in this final rule. Instead, we assume the following:</P>
                    <P>• Because of the payment consequences for not adopting the provisions of this final rule, we assume all 54,770 MIPS eligible clinicians (individual and group), a subset of the 199,543 estimated individual and group physician practices, would adopt the provisions in this rule in CY 2027 (the first year for payer compliance). This assumption of compliance by all MIPS eligible clinicians (individual and group) in the first year of payer compliance is consistent with the assumptions in the proposed rule (87 FR 76351).</P>
                    <P>
                        • As in the proposed rule, by 2036, we assume 50 percent of all individual and physician practices will adopt the provisions of this final rule. The reasons for this assumption are fully discussed in the proposed rule (87 FR 76351). However, we acknowledge that 78 percent of providers have adopted EHRs, in part to meet ONC requirements.
                        <SU>197</SU>
                        <FTREF/>
                         Therefore, this estimate of 50 percent is already an underestimate of the percent of individual and physician practices who would adopt and benefit from the provisions of this rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>197</SU>
                             Office of the National Coordinator for Health Information Technology (n.d.). National Trends in Hospital and Physician Adoption of Electronic Health Records. Retrieved from 
                            <E T="03">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records#:~:text=Office%20of%20the%20National%20Coordinator,IT%20Quick%2DStat%20%2361.&amp;text=As%20of%202021%2C%20nearly%204,%25)%20adopted%20a%20certified%20EHR.</E>
                        </P>
                    </FTNT>
                    <P>• We do not assume a constant increase per year but rather a gradual increase per year, starting with the participation of 54,770 MIPS eligible clinicians in 2027 and growing exponentially to 99,772 (50 percent of 199,543) individual and physician group practices in 2036.</P>
                    <P>
                        Applying these assumptions, based on the 2022 estimates results (as shown in 
                        <PRTPAGE P="8969"/>
                        Table K6), is at least a $15.8 billion ($15,829.3 million) savings over 10 years for individual and group physician practices. If we include hospitals by increasing the amount by 4 percent, the estimate would be at least $16.5 billion ($16,461.7 million). The estimate rounded to the nearest billion is at least $16 billion. Had we used the 2021 estimates we would obtain $15 billion in savings.
                    </P>
                    <P>This $16 billion revised estimate differs from the $15 billion estimate presented in the proposed rule is due to the change noted in Table K3: a 7.7 percent increase in hours per week spent on prior authorization (14 hours in 2022 versus 13 hours in 2021 based on the AMA survey). This result is consistent with comments from industry who thought our estimates were too low regarding the impact of prior authorization on practices and hospitals. After adjusting for this change estimate, and as noted in Tables K4 and K5, we obtain the additional savings potential. Note that the range of savings based on different assumptions of savings per staff, $13 to $20 billion over 10 years, still includes the estimate of $15 billion as noted in the proposed rule.</P>
                    <GPH SPAN="3" DEEP="244">
                        <GID>ER08FE24.028</GID>
                    </GPH>
                    <P>The headers of Table K6 show the logic and sources of the column entries. The reduced hours per year per practice spent on prior authorization for 2027 is calculated as shown here: 16.1 million hours equals 294 hours per year per practice × 199,543 practices × 27.45 percent participation. Similarly, the dollar savings per year per practice resulting from reduced time spent on prior authorization, $21,026, obtained from Table K5, when multiplied by 27.45 percent of all 199,543 group and physician practices yields $1.2 billion ($1,151.6 million) reduced dollar spending in 2027.</P>
                    <P>By summing the reduced hours and dollars per year we obtain an aggregate reduction of at least 220.97 million hours and at least $15.8 billion ($15,829.3 million) in reduced spending on paperwork activities. Finally, by adding 4 percent of these numbers to account for hospitals, we obtain a total annual reduction of at least 229.27 million hours and at least a $16.5 billion ($16,461.7 million) reduction.</P>
                    <P>As in the proposed rule, we obtained a range of estimates by varying the assumptions of Table K5 which assume that physicians, nurses, and clerical staff save 10, 50, and 25 percent respectively. If we assume that all staff types uniformly reduce hours spent by 33 percent, then dollar spending is reduced by $13.2 billion without hospitals to $13.7 billion with hospitals factored in over 10 years. If we assume that all staff types uniformly reduce hours spent by 50 percent, then dollar spending is reduced by about $19.8 billion without hospitals to $20.6 billion with hospitals factored in. Thus, the range of savings, $10 billion to $20 billion presented in the proposed rule, is slightly narrowed in this final rule to $13 to $20 billion, including providers and hospitals.</P>
                    <HD SOURCE="HD2">I. Summary of Costs to the Federal Government</HD>
                    <P>In this section, we present a 10-year Summary Table of costs (Table K9), an analysis of Federal impacts, and the Monetized Table (Table K11).</P>
                    <P>To analyze the cost of this final rule to the Federal Government, we utilize a method of allocating costs by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 365 parent organizations, including state Medicaid and CHIP agencies, there is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization's expenditures on the different programs is not publicly available.</P>
                    <P>To address this, we utilize the same method used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums among the various programs. The advantages and disadvantages of such an approach are fully discussed in that rule. Table K7 presents the 2021 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by program. This allocation of cost by program forms a basis to calculate the Federal Government's cost for the proposed provisions of this rule.</P>
                    <GPH SPAN="3" DEEP="97">
                        <PRTPAGE P="8970"/>
                        <GID>ER08FE24.029</GID>
                    </GPH>
                    <P>To calculate Federal costs for MA organizations, we use the CMS internal data used to produce the CMS Trustees' Report. This internal data indicates that the Trust Fund will pay about 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99 percent of plans bidding below the benchmark) are borne by the plans. Similarly, we can calculate the Federal Medicaid payments using the percentages in Table K8.</P>
                    <GPH SPAN="3" DEEP="60">
                        <GID>ER08FE24.030</GID>
                    </GPH>
                    <P>Table K8 is based on the most recent projections of the CMS OACT for the FY 2024 Budget.</P>
                    <P>We illustrate the interpretation of the column by explaining the items in the 2025 column. The number at the bottom of the column, 65.40 percent, answers the question “What proportion of the interoperability systems costs for Medicaid is the Federal Government expected to pay?” There are two components to this calculation.</P>
                    <P>
                        The first is the share of Medicaid managed care. Those costs are directly paid by the MCOs, which in turn would be expected to raise administrative costs for those plans. The Federal share of that is: Federal Medical Assistance Percentage (FMAP) 
                        <SU>198</SU>
                        <FTREF/>
                         × the managed care (MC) share of Medicaid; for 2025, this is 58.10 percent × 56.80 percent. The second is the share of the FFS program costs. The FFS program side of Medicaid would have higher administrative costs. The Federal share of this would be 90 percent in year 1 and 75 percent after year 1. For 2025, this is equal to 75 percent × (1-56.8 percent). The sum of these two components, 58.10 percent × 56.80 percent + 75 percent × (1−56.8 percent), equals 65.40 percent as shown in the bottom row. When we multiply, in Table K9, the total annual cost of interoperability for Medicaid by 65.40 percent we obtain the amount the Federal Government is expected to pay for the interoperability system costs for Medicaid.
                    </P>
                    <FTNT>
                        <P>
                            <SU>198</SU>
                             Federal Medical spending is determined by the amount that states spend. The Federal share for most health care services is determined by the FMAP. The FMAP is based on a formula that provides higher reimbursement to states with lower per capita incomes relative to the national average.
                        </P>
                    </FTNT>
                    <P>It should be noted that although the compliance dates for policies in this final rule that do not require API development or enhancement are in 2026, and the compliance dates for policies that require API development or enhancement are in 2027. We expect plans to begin constructing software systems for the provisions that require API development or enhancement upon publication of this final rule.</P>
                    <P>Based on the discussion presented in Tables K7 and K8, Table K9 presents the calculation of all numerical impacts of this final rule by program, government, and QHP issuers on the FFEs.</P>
                    <BILCOD>BILLING CODE 4150-28-P</BILCOD>
                    <GPH SPAN="3" DEEP="623">
                        <PRTPAGE P="8971"/>
                        <GID>ER08FE24.031</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-28-C</BILCOD>
                    <P>For Table K9:</P>
                    <P>
                        • As explained in connection with Table J9 in the Collection of Information section, the data in Table K9 is based on 2027 compliance dates for policies that require API development or enhancement and the Electronic Prior Authorization measure for MIPS and the Medicare Promoting Interoperability Program and compliance dates in 2026 
                        <PRTPAGE P="8972"/>
                        for the policies that do not require API development or enhancement.
                    </P>
                    <P>• The bottom-line totals in the columns of Table J9 labeled “1st Year Cost” through “4th Year Cost” are the totals found in the “Total Cost” column of Table K9 in rows 2024 through 2027 respectively. The totals in the column “4th and Subsequent Year Costs” in Table J9 are found in the rows labeled 2028 through 2033 in the “Total Cost” column of Table K9.</P>
                    <P>• The Total Cost to MIPS Eligible Clinicians, Eligible Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible clinicians (including individual clinicians and groups), eligible hospitals, and CAHs, as found in Table J9 for years 2027 and further.</P>
                    <P>• The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table K9, $1.6 billion. This number uses the primary estimates for the provisions that require API development or enhancement. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively.</P>
                    <P>• The Cost of Final Rule to Payers by Program columns: We applied the percentages from Table K7 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).</P>
                    <P>• The Cost of Final Rule to Government by Program columns: For the QHP issuers on the FFEs, the government does not pay anything. For managed care the Government pays approximately 34 percent (the exact amount varying slightly from year to year and was obtained from projections by OACT). For Medicaid, we applied the percentages of payment by the Federal Government discussed in the narrative in Table K8 to obtain the cost by program.</P>
                    <P>
                        • PTC Payments: The Government does not reimburse QHP issuers on the FFEs, neither prospectively nor retrospectively, for their expenses in furnishing health benefits. However, the government offers QHP enrollees PTCs to help cover the cost of premiums for the plans. QHP issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness—see, however, a caveat elsewhere in this RIA), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market QHPs on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Because PTC is available only if an individual purchases a QHP on an Exchange and the individual generally has a household income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. Note, the Inflation Reduction Act of 2022 (IRA) 
                        <SU>199</SU>
                        <FTREF/>
                         extended the expanded PTC eligibility provision set forth in the American Rescue Plan Act of 2021 (ARP) through the 2025 plan year.
                    </P>
                    <FTNT>
                        <P>
                            <SU>199</SU>
                             H.R. 5376—117th Congress (2021-2022): Inflation Reduction Act of 2022 (2022, August 16). Retrieved from 
                            <E T="03">https://www.congress.gov/bill/117th-congress/house-bill/5376.</E>
                        </P>
                    </FTNT>
                    <P>In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. Specifically, the methodology to estimate the PTC impact of the projected expense burden is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest-cost silver plan and the eligible individual's household income. The estimate of these impacts uses the assumption that the industry would increase the second lowest-cost silver plan premium rate in the same amount as the overall premium rate increase. This assumption allows the application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact on PTC payments.</P>
                    <P>• The total cost to the government is the sum of payments related to each program. This payment is a transfer from the Government to payers for MA and Medicaid, CHIP, and QHP enrollees.</P>
                    <P>• For MA organizations, Medicaid and CHIP, the remaining costs are the difference between the total cost to payers and what the Federal Government pays. For the individual market, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce the expenses of the payers.</P>
                    <P>The dollar savings from reduced paperwork burden for an increase in using electronic prior authorization (Tables K4 and K5) is not included in Table K9.</P>
                    <P>Table K10 describes how the various plans (and states) would bear the costs remaining after federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612). In the table we explain the possible ways payers may manage extra implementation costs. We emphasize that Table K10 only includes possibilities. The impacted payers would make decisions about how to defray these remaining costs based on market dynamics and internal business decisions; we have no uniform way of predicting what these actual behaviors and responses will be.</P>
                    <GPH SPAN="3" DEEP="194">
                        <PRTPAGE P="8973"/>
                        <GID>ER08FE24.032</GID>
                    </GPH>
                    <P>• Individual Market Plans: Individual market plans have the option of absorbing costs or passing costs to enrollees in the form of higher premiums. In some cases, for reasons of market competitiveness, plans may absorb the increased costs rather than increase premiums.</P>
                    <P>
                        • Medicaid and CHIP: Assuming roughly 71 million patients enrolled nationally (inclusive of state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities), Medicaid and CHIP would see an added cost of under a dollar per beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and CHIP programs of several thousand dollars.
                        <SU>200</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>200</SU>
                             Centers for Medicare and Medicaid Services Newsroom (2020, January 30). Medicaid Facts and Figures | CMS. Retrieved from 
                            <E T="03">https://www.cms.gov/newsroom/fact-sheets/medicaid-facts-and-figures.</E>
                        </P>
                    </FTNT>
                    <P>• Medicare Advantage: In their bids (submitted in the month of June prior to the beginning of the coverage year), MA plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: temporarily absorbing costs by reducing profit margins, reducing the supplemental benefits paid for by the rebates, or raising enrollee cost-sharing or premium. We believe many plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either absorb losses for 1 year or reduce rebate-funded supplemental benefits.</P>
                    <P>We received no comments specific to Table K10 or the methods impacted payers will use to deal with the costs of this rule and are therefore finalizing it as is.</P>
                    <HD SOURCE="HD2">J. Accounting Statement and Table</HD>
                    <P>
                        As required by OMB Circular A-4 (available at 
                        <E T="03">https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A4/a-4.pdf</E>
                        ), the following table, Table K11, summarizes the classification of annualized costs associated with the provisions of this final rule for the 10 years, 2024 through 2033. This accounting table is based on Table K9 and includes the costs of this final rule to certain providers, including hospitals and CAHs, MA organizations, state Medicaid and CHIP programs, and QHP issuers on the FFEs. It does not include the potential savings from Table K6 arising from reduced burden due to providers, hospitals, and CAHs using electronic prior authorization. Minor discrepancies in totals reflect use of underlying spreadsheets, rather than intermediate rounded amounts. Table K11 is stated in 2023 dollars, with expected compliance dates in 2027 for the provisions of this final rule that require API development or enhancement.
                    </P>
                    <GPH SPAN="3" DEEP="167">
                        <GID>ER08FE24.033</GID>
                    </GPH>
                    <PRTPAGE P="8974"/>
                    <P>In accordance with the provisions of Executive Order 12866, this final rule was reviewed by OMB.</P>
                    <P>Chiquita Brooks-LaSure, Administrator of the Centers for Medicare &amp; Medicaid Services, approved this document on January 12, 2024.</P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>42 CFR Part 422</CFR>
                        <P>Administrative practice and procedure, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 431</CFR>
                        <P>Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements, State fair hearings.</P>
                        <CFR>42 CFR Part 435</CFR>
                        <P>Aid to Families with Dependent Children, Grant programs—health, Medicaid, Notices, Reporting and recordkeeping requirements, Supplemental Security Income (SSI), Wages.</P>
                        <CFR>42 CFR Part 438</CFR>
                        <P>Grant programs—health, Medicaid, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 440</CFR>
                        <P>Grant programs—health, Medicaid.</P>
                        <CFR>42 CFR Part 457</CFR>
                        <P>Administrative practice and procedure, Grant programs—health, Health insurance, Reporting and recordkeeping requirements.</P>
                        <CFR>45 CFR Part 156</CFR>
                        <P>Administrative practice and procedure, Advertising, Brokers, Conflict of interests, Consumer protection, Grant programs—health, Grants administration, Health care, Health insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Intergovernmental relations, Loan programs—health, Medicaid, Organization and functions (Government agencies), Prescription drugs, Public assistance programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth.</P>
                    </LSTSUB>
                    <P>For the reasons set forth in the preamble, the Centers for Medicare &amp; Medicaid Services amends 42 CFR chapter IV and the Department of Health and Human Services amends 45 CFR part 156 as set forth below:</P>
                    <TITLE>TITLE 42—PUBLIC HEALTH</TITLE>
                    <PART>
                        <HD SOURCE="HED">PART 422—MEDICARE ADVANTAGE PROGRAM</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>1. The authority citation for part 422 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P>42 U.S.C. 1302, 1306, 1395w-22 through 1395w-28, and 1395hh.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>2. Section 422.119 is amended by—</AMDPAR>
                        <AMDPAR>a. In paragraph (b)(1)(ii), removing the word “and” at the end of the paragraph;</AMDPAR>
                        <AMDPAR>b. Revising paragraph (b)(1)(iii);</AMDPAR>
                        <AMDPAR>c. Adding paragraphs (b)(1)(iv) and (v); and</AMDPAR>
                        <AMDPAR>d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (h).</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 422.119</SECTNO>
                            <SUBJECT>Access to and exchange of health data and plan information.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(1) * * *</P>
                            <P>(iii) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the MA organization no later than 1 business day after the MA organization receives the data; and</P>
                            <P>(iv) Beginning January 1, 2027, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined in paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section.</P>
                            <P>(A) The prior authorization request and decision, including all of the following, as applicable:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The prior authorization status.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The date the prior authorization was approved or denied.
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) The date or circumstance under which the prior authorization ends.
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) The items and services approved.
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) If denied, a specific reason why the request was denied.
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Related structured administrative and clinical documentation submitted by a provider.
                            </P>
                            <P>(B) The information in paragraph (b)(1)(iv)(A) of this section must—</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Be accessible no later than 1 business day after the MA organization receives a prior authorization request;
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Be updated no later than 1 business day after any status change; and
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.
                            </P>
                            <P>(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the MA organization, including any products that constitute a Part D drug, as defined by § 423.100 of this chapter, and are covered under the Medicare Part D benefit.</P>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);</P>
                            <STARS/>
                            <P>(4) * * *</P>
                            <P>(ii) * * *</P>
                            <P>(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data specified in paragraph (b) of this section or §§ 422.120, 422.121, and 422.122 through the required APIs.</P>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to, criteria that rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Reporting on Patient Access API usage.</E>
                                 Beginning in 2026, by March 31 following any calendar year that it offers an MA plan, an MA organization must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the contract level in the form and manner specified by the Secretary:
                            </P>
                            <P>(1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee.</P>
                            <P>(2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee.</P>
                            <STARS/>
                            <P>
                                (h) 
                                <E T="03">Applicability.</E>
                                 An MA organization must comply with the requirements of this section beginning in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, unless otherwise specified, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data:
                            </P>
                            <P>(1) With a date of service on or after January 1, 2016; and</P>
                            <P>(2) That are maintained by the MA organization.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>3. Section 422.121 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.121</SECTNO>
                            <SUBJECT>Access to and exchange of health data for providers and payers.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">
                                    Application programming interface to support data exchange from 
                                    <PRTPAGE P="8975"/>
                                    payers to providers—Provider Access API.
                                </E>
                                 Beginning January 1, 2027, an MA organization must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an application programming interface (API) conformant with all of the following:
                            </P>
                            <P>(i) Section 422.119(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Provider access.</E>
                                 Make the data specified at § 422.119(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that are maintained by the MA organization available to in-network providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:
                            </P>
                            <P>(i) The MA organization authenticates the identity of the provider that requests access and attributes the enrollee to the provider under the attribution process described in paragraph (a)(3) of this section.</P>
                            <P>(ii) The enrollee does not opt out as described in paragraph (a)(4) of this section.</P>
                            <P>(iii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (3) 
                                <E T="03">Attribution.</E>
                                 Establish and maintain a process to associate enrollees with their in-network providers to enable data exchange via the Provider Access API.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Opt out and patient educational resources.</E>
                                 (i) Establish and maintain a process to allow an enrollee or the enrollee's personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the MA organization makes enrollee information available via the Provider Access API and at any time while the enrollee is enrolled with the MA organization.
                            </P>
                            <P>(ii) Provide information to enrollees in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows:</P>
                            <P>(A) Before the first date on which the MA organization makes enrollee information available through the Provider Access API.</P>
                            <P>(B) No later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later.</P>
                            <P>(C) At least annually.</P>
                            <P>(D) In an easily accessible location on its public website.</P>
                            <P>
                                (5) 
                                <E T="03">Provider resources.</E>
                                 Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting enrollee data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the MA organization's attribution process to associate enrollees with their providers.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Application programming interface to support data exchange between payers—Payer-to-Payer API.</E>
                                 Beginning January 1, 2027, an MA organization must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an API conformant with all of the following:
                            </P>
                            <P>(i) Section 422.119(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Opt in.</E>
                                 Establish and maintain a process to allow enrollees or their personal representatives to opt into the MA organization's payer to payer data exchange with the enrollee's previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time.
                            </P>
                            <P>(i) The opt in process must be offered as follows:</P>
                            <P>(A) To current enrollees, no later than the compliance date.</P>
                            <P>(B) To new enrollees, no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later.</P>
                            <P>(ii) If an enrollee does not respond or additional information is necessary, the MA organization must make reasonable efforts to engage with the enrollee to collect this information.</P>
                            <P>
                                (3) 
                                <E T="03">Identify previous and concurrent payers.</E>
                                 Establish and maintain a process to identify a new enrollee's previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows:
                            </P>
                            <P>(i) For current enrollees, no later than the compliance date.</P>
                            <P>(ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later.</P>
                            <P>(iii) If an enrollee does not respond or additional information is necessary, the MA organization must make reasonable efforts to engage with the enrollee to collect this information.</P>
                            <P>
                                (4) 
                                <E T="03">Exchange request requirements.</E>
                                 Exchange enrollee data with other payers, consistent with the following requirements:
                            </P>
                            <P>(i) The MA organization must request the data listed in paragraph (b)(4)(ii) of this section through the enrollee's previous payers' API, if all the following conditions are met:</P>
                            <P>(A) The enrollee has opted in, as described in paragraph (b)(2) of this section.</P>
                            <P>(B) The exchange is not prohibited by other applicable law.</P>
                            <P>(ii) The data to be requested are all of the following with a date of service within 5 years before the request:</P>
                            <P>(A) Data specified in § 422.119(b) excluding the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Provider remittances and enrollee cost-sharing information.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Denied prior authorizations.
                            </P>
                            <P>(B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations.</P>
                            <P>(iii) The MA organization must include an attestation with this request affirming that the enrollee is enrolled with the MA organization and has opted into the data exchange.</P>
                            <P>(iv) The MA organization must complete this request as follows:</P>
                            <P>(A) No later than 1 week after the payer has sufficient identifying information about previous payers and the enrollee has opted in.</P>
                            <P>(B) At an enrollee's request, within 1 week of the request.</P>
                            <P>(v) The MA organization must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the enrollee, any data made available by other payers in response to the request.</P>
                            <P>
                                (5) 
                                <E T="03">Exchange response requirements.</E>
                                 Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the MA organization to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met:
                            </P>
                            <P>(i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange.</P>
                            <P>(ii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (6) 
                                <E T="03">Concurrent coverage data exchange requirements.</E>
                                 When an enrollee has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, an MA organization must do the following, through the API required in paragraph (b)(1) of this section:
                            </P>
                            <P>
                                (i) Request the enrollee's data from all known concurrent payers as described 
                                <PRTPAGE P="8976"/>
                                in paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled with both payers.
                            </P>
                            <P>(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the MA organization may exclude any data that were previously sent to or originally received from the concurrent payer.</P>
                            <P>
                                (7) 
                                <E T="03">Patient educational resources.</E>
                                 Provide information to enrollees in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The MA organization must provide the following resources:
                            </P>
                            <P>(i) When requesting an enrollee's permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section.</P>
                            <P>(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees.</P>
                            <P>(iii) In an easily accessible location on its public website.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>4. Section 422.122 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.122</SECTNO>
                            <SUBJECT>Prior authorization requirements.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Communicating a reason for denial.</E>
                                 Beginning January 1, 2026, if the MA organization denies a prior authorization request (excluding request for coverage of drugs as defined in § 422.119(b)(1)(v)), in accordance with the timeframes established in §§ 422.568(b)(1) and 422.572(a)(1), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Prior Authorization Application Programming Interface (API).</E>
                                 Beginning January 1, 2027, an MA organization must implement and maintain an API conformant with § 422.119(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that—
                            </P>
                            <P>(1) Is populated with the MA organization's list of covered items and services (excluding drugs, as defined in § 422.119(b)(1)(v)) that require prior authorization;</P>
                            <P>(2) Can identify all documentation required by the MA organization for approval of any items or services that require prior authorization;</P>
                            <P>(3) Supports a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response, as described in 45 CFR part 162; and</P>
                            <P>(4) Communicates the following information about prior authorization requests:</P>
                            <P>(i) Whether the MA organization—</P>
                            <P>(A) Approves the prior authorization request (and the date or circumstance under which the authorization ends);</P>
                            <P>(B) Denies the prior authorization request; or</P>
                            <P>(C) Requests more information.</P>
                            <P>(ii) If the MA organization denies the prior authorization request, it must include a specific reason for the denial.</P>
                            <P>(5) In addition to the requirements of this section, an MA organization using prior authorization polices or making prior authorization decisions must meet all other applicable requirements under this part, including § 422.138 and the requirements in subpart M of this part.</P>
                            <P>
                                (c) 
                                <E T="03">Publicly reporting prior authorization metrics.</E>
                                 Beginning in 2026, following each calendar year that it offers an MA plan, an MA organization must report prior authorization data, excluding data on drugs as defined in § 422.119(b)(1)(v), at the MA contract level by March 31. The MA organization must make the following data from the previous calendar year publicly accessible by posting them on its website:
                            </P>
                            <P>(1) A list of all items and services that require prior authorization.</P>
                            <P>(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                            <P>(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                            <P>(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(8) The average and median time that elapsed between the submission of a request and a determination by the MA plan, for standard prior authorizations, aggregated for all items and services.</P>
                            <P>(9) The average and median time that elapsed between the submission of a request and a decision by the MA plan for expedited prior authorizations, aggregated for all items and services.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>5. Section 422.568 is amended by—</AMDPAR>
                        <AMDPAR>a. Revising paragraph (b)(1);</AMDPAR>
                        <AMDPAR>b. Redesignating paragraph (b)(2) as paragraph (b)(3);</AMDPAR>
                        <AMDPAR>c. Adding new paragraph (b)(2); and</AMDPAR>
                        <AMDPAR>d. In newly redesignated paragraph (b)(3), removing the phrase “under the provisions in paragraph (b)(1)(i) of this section” and adding in its place the phrase “under the provisions in paragraph (b)(2) of this section.”</AMDPAR>
                        <P>The revision and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 422.568</SECTNO>
                            <SUBJECT>Standard timeframes and notice requirements for organization determinations.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Requests for service or item.</E>
                                 Except as provided in paragraph (b)(2) of this section, when a party has made a request for an item or service, the MA organization must notify the enrollee of its determination as expeditiously as the enrollee's health condition requires but no later than either of the following:
                            </P>
                            <P>(i) For a service or item not subject to the prior authorization rules in § 422.122, 14 calendar days after receiving the request for the standard organization determination.</P>
                            <P>(ii) Beginning on or after January 1, 2026, for a service or item subject to the prior authorization rules in § 422.122, 7 calendar days after receiving the request for the standard organization determination.</P>
                            <P>
                                (2) 
                                <E T="03">Extensions; requests for service or item</E>
                                —(i) 
                                <E T="03">Extension of timeframe on a request for service or item.</E>
                                 The MA organization may extend the timeframe by up to 14 calendar days under any of the following circumstances:
                            </P>
                            <P>(A) The enrollee requests the extension.</P>
                            <P>(B) The extension is justified and in the enrollee's interest due to the need for additional medical evidence from a noncontract provider that may change an MA organization's decision to deny an item or service.</P>
                            <P>(C) The extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the enrollee's interest.</P>
                            <P>
                                (ii) 
                                <E T="03">Notice of extension.</E>
                                 (A) When the MA organization extends the timeframe, it must—
                            </P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Notify the enrollee in writing of the reasons for the delay; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Inform the enrollee of the right to file an expedited grievance if the enrollee disagrees with the MA organization's decision to grant an extension.
                            </P>
                            <P>
                                (B) The MA organization must notify the enrollee of its determination as expeditiously as the enrollee's health 
                                <PRTPAGE P="8977"/>
                                condition requires, but no later than upon expiration of the extension.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 422.570</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>6. Section 422.570 is amended in paragraph (d)(1) by removing the phrase “request to the standard timeframe and make the determination within the 72-hour or 14-day timeframe, as applicable, established” and adding in its place the phrase “request to a standard organization determination and make the determination within the applicable timeframe, established”.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>
                            7. Section 422.631 is amended by revising paragraphs (d)(2)(i)(B), (d)(2)(iv)(B)(
                            <E T="03">1</E>
                            ), and (d)(2)(iv)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) to read as follows:
                        </AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.631</SECTNO>
                            <SUBJECT>Integrated organization determinations.</SUBJECT>
                            <STARS/>
                            <P>(d) * * *</P>
                            <P>(2) * * *</P>
                            <P>(i) * * *</P>
                            <P>(B) Except as described in paragraph (d)(2)(i)(A) of this section, the applicable integrated plan must send a notice of its integrated organization determination as expeditiously as the enrollee's health condition requires but no later than either of the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) For a service or item not subject to the prior authorization rules in § 422.122, 14 calendar days after receiving the request for the standard integrated organization determination.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Beginning on or after January 1, 2026, for a service or item subject to the prior authorization rules in § 422.122, 7 calendar days after receiving the request for the standard integrated organization determination.
                            </P>
                            <STARS/>
                            <P>(iv) * * *</P>
                            <P>(B) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Automatically transfer a request to the standard timeframe and make the determination within the applicable timeframe established in paragraph (d)(2)(i)(B) of this section for a standard integrated organization determination. The timeframe begins the day the applicable integrated plan receives the request for expedited integrated organization determination.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) * * *
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Explains that the applicable integrated plan will process the request using the timeframe for standard integrated organization determinations;
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>8. The authority citation for part 431 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>9. Section 431.60 is amended by—</AMDPAR>
                        <AMDPAR>a. Revising paragraph (b)(3);</AMDPAR>
                        <AMDPAR>b. Adding paragraphs (b)(5) and (6);</AMDPAR>
                        <AMDPAR>c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);</AMDPAR>
                        <AMDPAR>d. Removing paragraph (g);</AMDPAR>
                        <AMDPAR>e. Redesignating paragraph (f) as paragraph (g); and</AMDPAR>
                        <AMDPAR>f. Adding new paragraph (f) and paragraph (h).</AMDPAR>
                        <P>The revisions and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 431.60</SECTNO>
                            <SUBJECT>Beneficiary access to and exchange of data.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(3) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the State no later than 1 business day after the State receives the data; and</P>
                            <STARS/>
                            <P>(5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section.</P>
                            <P>(i) The prior authorization request and decision, including all of the following, as applicable:</P>
                            <P>(A) The prior authorization status.</P>
                            <P>(B) The date the prior authorization was approved or denied.</P>
                            <P>(C) The date or circumstance under which the prior authorization ends.</P>
                            <P>(D) The items and services approved.</P>
                            <P>(E) If denied, a specific reason why the request was denied.</P>
                            <P>(F) Related structured administrative and clinical documentation submitted by a provider.</P>
                            <P>(ii) The information in paragraph (b)(5)(i) of this section must—</P>
                            <P>(A) Be accessible no later than 1 business day after the State receives a prior authorization request;</P>
                            <P>(B) Be updated no later than 1 business day after any status change; and</P>
                            <P>(C) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.</P>
                            <P>(6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all drugs covered by the State.</P>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);</P>
                            <STARS/>
                            <P>(4) * * *</P>
                            <P>(ii) * * *</P>
                            <P>(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data specified in paragraph (b) of this section or §§ 431.61, 431.70, and 431.80, through the required APIs.</P>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools.</P>
                            <STARS/>
                            <P>
                                (f) 
                                <E T="03">Reporting on Patient Access API usage.</E>
                                 Beginning in 2026, by March 31 of each year, a State must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the State level in the form and manner specified by the Secretary:
                            </P>
                            <P>(1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary; and</P>
                            <P>(2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary.</P>
                            <STARS/>
                            <P>
                                (h) 
                                <E T="03">Applicability.</E>
                                 A State must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data:
                            </P>
                            <P>(1) With a date of service on or after January 1, 2016; and</P>
                            <P>(2) That are maintained by the State.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>10. Section 431.61 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 431.61</SECTNO>
                            <SUBJECT>Access to and exchange of health data for providers and payers.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application programming interface to support data exchange from payers to providers—Provider Access API.</E>
                                 Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an application programming interface (API) conformant with all of the following:
                            </P>
                            <P>(i) Section 431.60(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Provider access.</E>
                                 Make the data specified in § 431.60(b) with a date of 
                                <PRTPAGE P="8978"/>
                                service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State available to enrolled Medicaid providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:
                            </P>
                            <P>(i) The State authenticates the identity of the provider that requests access and attributes the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this section.</P>
                            <P>(ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section.</P>
                            <P>(iii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (3) 
                                <E T="03">Attribution.</E>
                                 Establish and maintain a process to associate beneficiaries with their enrolled Medicaid providers to enable data exchange via the Provider Access API.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Opt out and patient educational resources.</E>
                                 (i) Establish and maintain a process to allow a beneficiary or the beneficiary's personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the State makes beneficiary information available via the Provider Access API and at any time while the beneficiary is enrolled with the State.
                            </P>
                            <P>(ii) Provide information to beneficiaries in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows:</P>
                            <P>(A) Before the first date on which the State makes beneficiary information available through the Provider Access API.</P>
                            <P>(B) No later than 1 week after enrollment.</P>
                            <P>(C) At least annually.</P>
                            <P>(D) In an easily accessible location on its public website.</P>
                            <P>
                                (5) 
                                <E T="03">Provider resources.</E>
                                 Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting beneficiary data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the State's attribution process to associate beneficiaries with their providers.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Application programming interface to support data exchange between payers—Payer-to-Payer API.</E>
                                 Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an API conformant with all of the following:
                            </P>
                            <P>(i) Section 431.60(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Opt in.</E>
                                 Establish and maintain a process to allow beneficiaries or their personal representatives to opt into the State's payer to payer data exchange with the beneficiary's previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time.
                            </P>
                            <P>(i) The opt in process must be offered as follows:</P>
                            <P>(A) To current beneficiaries, no later than the compliance date.</P>
                            <P>(B) To new beneficiaries, no later than 1 week after enrollment.</P>
                            <P>(ii) If a beneficiary has coverage through any Medicaid MCO, prepaid inpatient health plan (PIHP), or prepaid ambulatory health plan (PAHP) within the same State while enrolled in Medicaid, the State must share their opt in permission with those MCO, PIHP, or PAHP to allow the Payer-to-Payer API data exchange described in this section.</P>
                            <P>(iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information.</P>
                            <P>
                                (3) 
                                <E T="03">Identify previous and concurrent payers.</E>
                                 Establish and maintain a process to identify a new beneficiary's previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows:
                            </P>
                            <P>(i) For current beneficiaries, no later than the compliance date.</P>
                            <P>(ii) For new beneficiaries, no later than 1 week after enrollment.</P>
                            <P>(iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information.</P>
                            <P>
                                (4) 
                                <E T="03">Exchange request requirements.</E>
                                 Exchange beneficiary data with other payers, consistent with the following requirements:
                            </P>
                            <P>(i) The State must request the data specified in paragraph (b)(4)(ii) of this section through the beneficiary's previous payers' API, if all the following conditions are met:</P>
                            <P>(A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except for data exchanges between a State Medicaid agency and its contracted MCOs, PIHPs, or PAHPs, which do not require a beneficiary to opt in.</P>
                            <P>(B) The exchange is not prohibited by other applicable law.</P>
                            <P>(ii) The data to be requested are all of the following with a date of service within 5 years before the request:</P>
                            <P>(A) Data specified in § 431.60(b), excluding the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Provider remittances and enrollee cost-sharing information.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Denied prior authorizations.
                            </P>
                            <P>(B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations.</P>
                            <P>(iii) The State must include an attestation with this request affirming that the beneficiary is enrolled with the State and has opted into the data exchange.</P>
                            <P>(iv) The State must complete this request as follows:</P>
                            <P>(A) No later than 1 week after the payer has sufficient identifying information about previous payers and the beneficiary has opted in.</P>
                            <P>(B) At a beneficiary's request, within 1 week of the request.</P>
                            <P>(v) The State must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the beneficiary, any data made available by other payers in response to the request.</P>
                            <P>
                                (5) 
                                <E T="03">Exchange response requirements.</E>
                                 Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the State to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met:
                            </P>
                            <P>(i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange.</P>
                            <P>(ii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (6) 
                                <E T="03">Concurrent coverage data exchange requirements.</E>
                                 When a beneficiary has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a State must do the following, through the API required in paragraph (b)(1) of this section:
                            </P>
                            <P>(i) Request the beneficiary's data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled with both payers.</P>
                            <P>
                                (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the 
                                <PRTPAGE P="8979"/>
                                requesting payer, the State may exclude any data that were previously sent to or originally received from the concurrent payer.
                            </P>
                            <P>
                                (7) 
                                <E T="03">Patient educational resources.</E>
                                 Provide information to applicants or beneficiaries in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The State must provide the following resources:
                            </P>
                            <P>(i) When requesting a beneficiary's permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section.</P>
                            <P>(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries.</P>
                            <P>(iii) In an easily accessible location on its public website.</P>
                            <P>
                                (c) 
                                <E T="03">Extensions and exemptions</E>
                                —(1) 
                                <E T="03">Extension.</E>
                                 (i) A State may submit a written application to request a one-time, 1-year extension of the requirements in paragraph (a) or (b) of this section (or paragraphs (a) and (b)) for its Medicaid fee-for-service (FFS) program. The written application must be submitted as part of the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures described in part 433, subpart C, of this chapter, and approved before the compliance date for the requirements to which the State is seeking an extension. It must include all the following:
                            </P>
                            <P>(A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid FFS program.</P>
                            <P>(B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance.</P>
                            <P>(C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>(ii) CMS grants the State's request if it determines, based on the information provided, that—</P>
                            <P>(A) The request adequately establishes a need to delay implementation; and</P>
                            <P>(B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>
                                (2) 
                                <E T="03">Exemption.</E>
                                 (i) A State operating a Medicaid program in which at least 90 percent of the State's Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as defined in § 438.2 of this chapter, may request an exemption for its FFS program from either or both of the following requirement(s):
                            </P>
                            <P>(A) Paragraph (a) of this section.</P>
                            <P>(B) Paragraphs (b)(1) and (3) through (7) of this section.</P>
                            <P>(ii) The State's exemption request must:</P>
                            <P>(A) Be submitted in writing as part of a State's annual APD for MMIS operations expenditures before the compliance date for the requirements to which the State is seeking an exemption.</P>
                            <P>(B) Include both of the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Documentation that the State meets the threshold for the exemption, based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” (or successor) report.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
                            </P>
                            <P>(iii) CMS grants the exemption if the State establishes to CMS's satisfaction that the State—</P>
                            <P>(A) Meets the threshold for the exemption; and</P>
                            <P>(B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.</P>
                            <P>(iv) The State's exemption expires if either—</P>
                            <P>(A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or</P>
                            <P>
                                (B)(
                                <E T="03">1</E>
                                ) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS managed care and FFS enrollment data.
                            </P>
                            <P>(v) If a State's exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following—</P>
                            <P>(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold.</P>
                            <P>(B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (a) or (b) (or paragraph0s (a) and (b)) of this section within 2 years of the expiration of the exemption.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>11. Section 431.80 is added to subpart B to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 431.80</SECTNO>
                            <SUBJECT>Prior authorization requirements.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Communicating a reason for denial.</E>
                                 Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of drugs as defined in § 431.60(b)(6)), in accordance with the timeframes established in § 440.230(e)(1) of this chapter, the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Prior Authorization Application Programming Interface (API).</E>
                                 Unless granted an extension or exemption under paragraph (c) of this section, beginning January 1, 2027, a State must implement and maintain an API conformant with § 431.60(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that—
                            </P>
                            <P>(1) Is populated with the State's list of covered items and services (excluding drugs, as defined in § 431.60(b)(6)) that require prior authorization;</P>
                            <P>(2) Can identify all documentation required by the State for approval of any items or services that require prior authorization;</P>
                            <P>(3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and</P>
                            <P>(4) Communicates the following information about prior authorization requests:</P>
                            <P>(i) Whether the State—</P>
                            <P>(A) Approves the prior authorization request (and the date or circumstance under which the authorization ends);</P>
                            <P>(B) Denies the prior authorization request; or</P>
                            <P>(C) Requests more information.</P>
                            <P>(ii) If the State denies the prior authorization request, it must include a specific reason for the denial.</P>
                            <P>
                                (c) 
                                <E T="03">Extensions and exemptions</E>
                                —(1) 
                                <E T="03">Extension.</E>
                                 (i) A State may submit a written application to request a one-time, 1-year extension of the requirements in paragraph (b) of this section for its Medicaid FFS program. The written application must be submitted as part of the State's annual APD for MMIS operations expenditures described in part 433, subpart C, of this chapter; and approved before the compliance date in paragraph (b) of this section. It must include all the following:
                            </P>
                            <P>
                                (A) A narrative justification describing the specific reasons why the 
                                <PRTPAGE P="8980"/>
                                State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid FFS program.
                            </P>
                            <P>(B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance.</P>
                            <P>(C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>(ii) CMS grants the State's request if it determines, based on the information provided, that—</P>
                            <P>(A) The request adequately establishes a need to delay implementation; and</P>
                            <P>(B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>
                                (2) 
                                <E T="03">Exemption.</E>
                                 (i) A State operating a Medicaid program in which at least 90 percent of the State's Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as defined in § 438.2 of this chapter, may request an exemption for its FFS program from the requirements in paragraph (b) of this section.
                            </P>
                            <P>(ii) The State's exemption request must:</P>
                            <P>(A) Be submitted in writing as part of a State's annual APD for MMIS operations expenditures before the compliance date in paragraph (b) of this section.</P>
                            <P>(B) The State's request must include both of the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Documentation that the State meets the threshold for the exemption, based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” (or successor) report.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
                            </P>
                            <P>(iii) CMS grants the exemption if the State establishes to CMS's satisfaction that the State—</P>
                            <P>(A) Meets the threshold for the exemption; and</P>
                            <P>(B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.</P>
                            <P>(iv) The State's exemption expires if either—</P>
                            <P>(A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or</P>
                            <P>
                                (B)(
                                <E T="03">1</E>
                                ) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS managed care and FFS enrollment data.
                            </P>
                            <P>(v) If a State's exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following—</P>
                            <P>(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold.</P>
                            <P>(B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (b) of this section within 2 years of the expiration of the exemption.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>12. Section 431.201 is amended by revising the definition of “Action” to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 431.201</SECTNO>
                            <SUBJECT>Definitions.</SUBJECT>
                            <STARS/>
                            <P>
                                <E T="03">Action</E>
                                 means one of the following:
                            </P>
                            <P>(1) A termination, suspension of, or reduction in covered benefits or services, including benefits or services for which there is a current approved prior authorization;</P>
                            <P>(2) A termination, suspension of, or reduction in Medicaid eligibility, or an increase in beneficiary liability, including a determination that a beneficiary must incur a greater amount of medical expenses to establish income eligibility in accordance with § 435.121(e)(4) or § 435.831 of this chapter;</P>
                            <P>(3) A determination that a beneficiary is subject to an increase in premiums or cost-sharing charges under subpart A of part 447 of this chapter; or</P>
                            <P>(4) A determination by a skilled nursing facility or nursing facility to transfer or discharge a resident and an adverse determination by a State regarding the preadmission screening and resident review requirements of section 1919(e)(7) of the Act.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>13. Section 431.220 is amended by—</AMDPAR>
                        <AMDPAR>a. In paragraph (a)(1)(iv), removing the term “or” from the end of the paragraph;</AMDPAR>
                        <AMDPAR>b. In paragraph (a)(1)(v), removing the period from the end of the paragraph and adding in its place “; or”; and</AMDPAR>
                        <AMDPAR>c. Adding paragraph (a)(1)(vi).</AMDPAR>
                        <P>The addition reads as follows:</P>
                        <SECTION>
                            <SECTNO>§ 431.220</SECTNO>
                            <SUBJECT>When a hearing is required.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>(1) * * *</P>
                            <P>(vi) A prior authorization decision.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 435—ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="435">
                        <AMDPAR>14. The authority citation for part 435 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="435">
                        <AMDPAR>15. Section 435.917 is amended by—</AMDPAR>
                        <AMDPAR>a. Revising the headings of paragraphs (a) and (b); and</AMDPAR>
                        <AMDPAR>b. Revising paragraph (b)(2).</AMDPAR>
                        <P>The revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 435.917</SECTNO>
                            <SUBJECT>Notice of agency's decision concerning eligibility, benefits, or services.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Notice of determinations.</E>
                                 * * *
                            </P>
                            <P>
                                (b) 
                                <E T="03">Content of notice</E>
                                —* * *
                            </P>
                            <P>
                                (2) 
                                <E T="03">Notice of adverse action.</E>
                                 Notice of adverse action including denial, termination, or suspension of eligibility or change in benefits or services. Any notice of denial, termination, or suspension of Medicaid eligibility, or, in the case of beneficiaries receiving medical assistance, denial of or change in benefits or services must be consistent with § 431.210 of this chapter.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 438—MANAGED CARE</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>16. The authority citation for part 438 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>17. Section 438.9 is amended by revising paragraph (b)(7) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 438.9</SECTNO>
                            <SUBJECT>Provisions that apply to non-emergency medical transportation PAHPs.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(7) The PAHP standards in §§ 438.206(b)(1), 438.210, 438.214, 438.224, 438.230, and 438.242, excluding the requirement in § 438.242(b)(7), to comply with § 431.61(a) and (b) of this chapter.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 438.62</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>18. Section 438.62 is amended by removing paragraphs (b)(1)(vi) and (vii).</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>19. Section 438.210 is amended by—</AMDPAR>
                        <AMDPAR>a. Revising paragraphs (d)(1) and (d)(2)(i);</AMDPAR>
                        <AMDPAR>b. Redesignating paragraph (f) as paragraph (g); and</AMDPAR>
                        <AMDPAR>c. Adding new paragraph (f).</AMDPAR>
                        <P>The addition and revision read as follows:</P>
                        <SECTION>
                            <PRTPAGE P="8981"/>
                            <SECTNO>§ 438.210</SECTNO>
                            <SUBJECT>Coverage and authorization of services.</SUBJECT>
                            <STARS/>
                            <P>(d) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard authorization decisions.</E>
                                 (i) For standard authorization decisions, provide notice as expeditiously as the enrollee's condition requires and:
                            </P>
                            <P>(A) For rating periods that start before January 1, 2026, within state established time frames that may not exceed 14 calendar days after receiving the request for service.</P>
                            <P>(B) For rating periods that start on or after January 1, 2026, within state established time frames that may not exceed 7 calendar days after receiving the request for service.</P>
                            <P>(ii) Standard authorization decisions may have an extension to the timeframes in paragraph (d)(1)(i) of this section up to 14 additional calendar days if—</P>
                            <P>(A) The enrollee or the provider requests the extension; or</P>
                            <P>(B) The MCO, PIHP, or PAHP justifies (to the State agency upon request) a need for additional information and how the extension is in the enrollee's interest.</P>
                            <P>(2) * * *</P>
                            <P>(i) For cases in which a provider indicates, or the MCO, PIHP, or PAHP determines, that following the standard timeframe could seriously jeopardize the enrollee's life or health or ability to attain, maintain, or regain maximum function, the MCO, PIHP, or PAHP must make an expedited authorization decision and provide notice as expeditiously as the enrollee's health condition requires and no later than 72 hours after receipt of the request for service.</P>
                            <STARS/>
                            <P>
                                (f) 
                                <E T="03">Publicly reporting prior authorization metrics.</E>
                                 Beginning January 1, 2026, following each calendar year it has a contract with a State Medicaid agency, the MCO, PIHP, or PAHP must report prior authorization data, excluding data on any and all drugs covered by the MCO, PIHP, or PAHP, at the plan level by March 31. The MCO, PIHP, or PAHP must make the following data from the previous calendar year publicly accessible by posting them on its website:
                            </P>
                            <P>(1) A list of all items and services that require prior authorization.</P>
                            <P>(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                            <P>(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                            <P>(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(8) The average and median time that elapsed between the submission of a request and a determination by the MCO, PIHP or PAHP, for standard prior authorizations, aggregated for all items and services.</P>
                            <P>(9) The average and median time that elapsed between the submission of a request and a decision by the MCO, PIHP or PAHP, for expedited prior authorizations, aggregated for all items and services.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>20. Section 438.242 is amended by revising paragraph (b)(5) and adding paragraphs (b)(7) through (9) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 438.242</SECTNO>
                            <SUBJECT>Health information systems.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(5) Subject to paragraph (b)(8) of this section, implement and maintain a Patient Access Application Programming Interface (API) required in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and:</P>
                            <P>(i) Include all encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating based on capitation payments and adjudicated claims and encounter data from any subcontractors.</P>
                            <P>(ii) Exclude covered outpatient drugs as defined in section 1927(k)(2) of the Act.</P>
                            <P>(iii) Report metrics specified in § 431.60(f) of this chapter at the plan level.</P>
                            <STARS/>
                            <P>(7) By the rating period beginning on or after January 1, 2027, comply with §§ 431.61(a), (b)(1) and (4) through (6), and (b)(7)(ii) and (iii) and 431.80(b) of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP</P>
                            <P>(8) By the rating period beginning on or after January 1, 2026, comply with § 431.80(a) of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP according to the decision timeframes in § 438.210(d).</P>
                            <P>(9) The following timeframes apply to paragraph (b)(5) of this section:</P>
                            <P>(i) Except for the requirements in § 431.60(b)(5), (g), and (h) of this chapter, comply with the requirements of § 431.60 of this chapter by January 1, 2021.</P>
                            <P>(ii) Comply with the requirements in § 431.60(b)(5) and (g) of this chapter by the rating period beginning on or after January 1, 2026.</P>
                            <P>(iii) Beginning in 2026, by March 31 following any year the MCO, PIHP, or PAHP operates, comply with the reporting requirements in § 431.60(h) of this chapter for the previous calendar year's data, in the form of aggregated, de-identified metrics, at the plan level.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 440—SERVICES: GENERAL PROVISIONS</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="440">
                        <AMDPAR>21. The authority citation for part 440 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="440">
                        <AMDPAR>22. Section 440.230 is amended by adding paragraph (e) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 440.230</SECTNO>
                            <SUBJECT>Sufficiency of amount, duration, and scope.</SUBJECT>
                            <STARS/>
                            <P>(e) For prior authorization requests for items and services (excluding drugs, as defined in § 431.60(b)(6) of this chapter), the State Medicaid agency must—</P>
                            <P>(1) Beginning January 1, 2026, make prior authorization decisions within the following timeframes:</P>
                            <P>(i) For a standard determination, as expeditiously as a beneficiary's health condition requires, but in no case later than 7 calendar days after receiving the request, unless a shorter minimum timeframe is established under State law. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the State agency determines that additional information from the provider is needed to make a decision.</P>
                            <P>(ii) For an expedited determination, as expeditiously as a beneficiary's health condition requires, but in no case later than 72 hours after receiving the request, unless a shorter minimum timeframe is established under State law.</P>
                            <P>
                                (2) Provide the beneficiary with notice of the agency's prior authorization decision in accordance with § 435.917 of this chapter and provide fair hearing rights, including advance notice, in accordance with part 431, subpart E, of this chapter.
                                <PRTPAGE P="8982"/>
                            </P>
                            <P>(3) Beginning in 2026, annually report prior authorization data, excluding data on drugs, as defined in § 431.60(b)(6) of this chapter, at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting them on its website:</P>
                            <P>(i) A list of all items and services that require prior authorization.</P>
                            <P>(ii) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(iii) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(iv) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                            <P>(v) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                            <P>(vi) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(vii) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(viii) The average and median time that elapsed between the submission of a request and a determination by the State Medicaid agency, for standard prior authorizations, aggregated for all items and services.</P>
                            <P>(ix) The average and median time that elapsed between the submission of a request and a decision by the State Medicaid agency for expedited prior authorizations, aggregated for all items and services.</P>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 457—ALLOTMENTS AND GRANTS TO STATES</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>23. The authority citation for part 457 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>24. Section 457.495 is amended by revising paragraph (d) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.495</SECTNO>
                            <SUBJECT>State assurance of access to care and procedures to assure quality and appropriateness of care.</SUBJECT>
                            <STARS/>
                            <P>(d) That decisions related to the prior authorization of health services are completed as follows:</P>
                            <P>
                                (1) 
                                <E T="03">Before January 1, 2026.</E>
                                 (i) In accordance with the medical needs of the patient, within 14 days after receipt of a request for services. A possible extension of up to 14 days may be permitted if the enrollee requests the extension or if the physician or health plan determines that additional information is needed; or
                            </P>
                            <P>(ii) In accordance with existing State law regarding prior authorization of health services.</P>
                            <P>
                                (2) 
                                <E T="03">On or after January 1, 2026.</E>
                                 (i) In accordance with the medical needs of the enrollee, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination. A possible extension of up to 14 days may be permitted if the enrollee requests the extension or if the physician or health plan determines the additional information is needed; or
                            </P>
                            <P>(ii) In accordance with existing State law regarding prior authorization of health services.</P>
                            <P>
                                (3) 
                                <E T="03">Enrollee notification.</E>
                                 Provide the enrollee with—
                            </P>
                            <P>(i) Notice of the State's prior authorization decision; and</P>
                            <P>(ii) Information on the enrollee's right to a review process, in accordance with § 457.1180.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>25. Section 457.700 is amended by revising paragraph (c) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.700</SECTNO>
                            <SUBJECT>Basis, scope, and applicability.</SUBJECT>
                            <STARS/>
                            <P>
                                (c) 
                                <E T="03">Applicability.</E>
                                 The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that §§ 457.730, 457.731, and 457.732 do not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care entities may meet the requirements of §§ 457.730, 457.731, and 457.732 by requiring the managed care entities to meet the requirements of § 457.1233(d).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>26. Section 457.730 is amended by—</AMDPAR>
                        <AMDPAR>a. Revising paragraph (b)(3);</AMDPAR>
                        <AMDPAR>b. Adding paragraphs (b)(5) and (6);</AMDPAR>
                        <AMDPAR>c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);</AMDPAR>
                        <AMDPAR>d. Removing paragraph (g);</AMDPAR>
                        <AMDPAR>e. Redesignating paragraph (f) as paragraph (g); and</AMDPAR>
                        <AMDPAR>f. Adding new paragraph (f) and paragraph (h).</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 457.730</SECTNO>
                            <SUBJECT>Beneficiary access to and exchange of data.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(3) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the State no later than 1 business day after the State receives the data; and</P>
                            <STARS/>
                            <P>(5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section.</P>
                            <P>(i) The prior authorization request and decision, including all of the following, as applicable:</P>
                            <P>(A) The prior authorization status.</P>
                            <P>(B) The date the prior authorization was approved or denied.</P>
                            <P>(C) The date or circumstance under which the prior authorization ends.</P>
                            <P>(D) The items and services approved.</P>
                            <P>(E) If denied, a specific reason why the request was denied.</P>
                            <P>(F) Related structured administrative and clinical documentation submitted by a provider.</P>
                            <P>(ii) The information in paragraph (b)(5)(i) of this section must—</P>
                            <P>(A) Be accessible no later than 1 business day after the State receives a prior authorization request;</P>
                            <P>(B) Be updated no later than 1 business day after any status change; and</P>
                            <P>(C) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.</P>
                            <P>(6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all drugs covered by the State.</P>
                            <P>(c) * * *</P>
                            <P>(1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);</P>
                            <STARS/>
                            <P>(4) * * *</P>
                            <P>(ii) * * *</P>
                            <P>(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data specified in paragraph (b) of this section or §§ 457.731, 457.732, and 457.760 through the required APIs.</P>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools.</P>
                            <STARS/>
                            <P>
                                (f) 
                                <E T="03">Reporting on Patient Access API usage.</E>
                                 Beginning in 2026, by March 31 of each year, a State must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the State level 
                                <PRTPAGE P="8983"/>
                                in the form and manner specified by the Secretary:
                            </P>
                            <P>(1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary; and</P>
                            <P>(2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary.</P>
                            <STARS/>
                            <P>
                                (h) 
                                <E T="03">Applicability.</E>
                                 A State must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data:
                            </P>
                            <P>(1) With a date of service on or after January 1, 2016; and</P>
                            <P>(2) That are maintained by the State.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>27. Section 457.731 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.731</SECTNO>
                            <SUBJECT>Access to and exchange of health data for providers and payers.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application programming interface to support data exchange from payers to providers—Provider Access API.</E>
                                 Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an application programming interface (API) conformant with all of the following:
                            </P>
                            <P>(i) Section 457.730(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Provider access.</E>
                                 Make the data specified in § 457.730(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State, available to enrolled CHIP providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:
                            </P>
                            <P>(i) The State authenticates the identity of the provider that requests access and attributes the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this section.</P>
                            <P>(ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section.</P>
                            <P>(iii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (3) 
                                <E T="03">Attribution.</E>
                                 Establish and maintain a process to associate beneficiaries with their enrolled CHIP providers to enable data exchange via the Provider Access API.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Opt out and patient educational resources.</E>
                                 (i) Establish and maintain a process to allow a beneficiary or the beneficiary's personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the State makes beneficiary information available via the Provider Access API and at any time while the beneficiary is enrolled with the State.
                            </P>
                            <P>(ii) Provide information to beneficiaries in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows:</P>
                            <P>(A) Before the first date on which the State makes beneficiary information available through the Provider Access API.</P>
                            <P>(B) No later than 1 week after enrollment.</P>
                            <P>(C) At least annually.</P>
                            <P>(D) In an easily accessible location on its public website.</P>
                            <P>
                                (5) 
                                <E T="03">Provider resources.</E>
                                 Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting beneficiary data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the State's attribution process to associate beneficiaries with their providers.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Application programming interface to support data exchange between payers—Payer-to-Payer API.</E>
                                 Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section a State must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an API conformant with all of the following:
                            </P>
                            <P>(i) Section 457.730(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Opt in.</E>
                                 Establish and maintain a process to allow beneficiaries or their personal representatives to opt into the State's payer to payer data exchange with the beneficiary's previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time.
                            </P>
                            <P>(i) The opt in process must be offered as follows:</P>
                            <P>(A) To current beneficiaries, no later than the compliance date.</P>
                            <P>(B) To new beneficiaries, no later than 1 week after enrollment.</P>
                            <P>(ii) If a beneficiary has coverage through any CHIP managed care entities within the same State while enrolled in CHIP, the State must share their opt in permission with those managed care entities to allow the Payer-to-Payer API data exchange described in this section.</P>
                            <P>(iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information.</P>
                            <P>
                                (3) 
                                <E T="03">Identify previous and concurrent payers.</E>
                                 Establish and maintain a process to identify a new beneficiary's previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows:
                            </P>
                            <P>(i) For current beneficiaries, no later than the compliance date.</P>
                            <P>(ii) For new beneficiaries, no later than 1 week after enrollment.</P>
                            <P>(iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information.</P>
                            <P>
                                (4) 
                                <E T="03">Exchange request requirements.</E>
                                 Exchange beneficiary data with other payers, consistent with the following requirements:
                            </P>
                            <P>(i) The State must request the data specified in paragraph (b)(4)(ii) of this section through the beneficiary's previous payers' API, if all the following conditions are met:</P>
                            <P>(A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except for data exchanges between a State CHIP agency and its contracted managed care entities, which do not require a beneficiary to opt in.</P>
                            <P>(B) The exchange is not prohibited by other applicable law.</P>
                            <P>(ii) The data to be requested are all of the following with a date of service within 5 years before the request:</P>
                            <P>(A) Data specified in § 457.730(b), excluding the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Provider remittances and enrollee cost-sharing information.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Denied prior authorizations.
                            </P>
                            <P>(B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations.</P>
                            <P>(iii) The State must include an attestation with this request affirming that the beneficiary is enrolled with the State and has opted into the data exchange.</P>
                            <P>(iv) The State must complete this request as follows:</P>
                            <P>
                                (A) No later than 1 week after the payer has sufficient identifying information about previous payers and the beneficiary has opted in.
                                <PRTPAGE P="8984"/>
                            </P>
                            <P>(B) At a beneficiary's request, within 1 week of the request.</P>
                            <P>(v) The State must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the beneficiary, any data made available by other payers in response to the request.</P>
                            <P>
                                (5) 
                                <E T="03">Exchange response requirements.</E>
                                 Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the State to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met:
                            </P>
                            <P>(i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange.</P>
                            <P>(ii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (6) 
                                <E T="03">Concurrent coverage data exchange requirements.</E>
                                 When a beneficiary has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a State must do the following, through the API required in paragraph (b)(1) of this section:
                            </P>
                            <P>(i) Request the beneficiary's data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled with both payers.</P>
                            <P>(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the State may exclude any data that were previously sent to or originally received from the concurrent payer.</P>
                            <P>
                                (7) 
                                <E T="03">Patient educational resources.</E>
                                 Provide information to applicants or beneficiaries in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The State must provide the following resources:
                            </P>
                            <P>(i) When requesting a beneficiary's permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section.</P>
                            <P>(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries.</P>
                            <P>(iii) In an easily accessible location on its public website.</P>
                            <P>
                                (c) 
                                <E T="03">Extensions and exemptions</E>
                                —(1) 
                                <E T="03">Extension.</E>
                                 (i) A State may submit a written application to request a one-time, 1-year extension of the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section for its CHIP fee-for-service program. The written application must be submitted as part of the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures, as described in part 433, subpart C, of this chapter, and approved before the compliance date for the requirements to which the State is seeking an extension. It must include all the following:
                            </P>
                            <P>(A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program.</P>
                            <P>(B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance.</P>
                            <P>(C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>(ii) CMS grants the State's request if it determines, based on the information provided, that—</P>
                            <P>(A) The request adequately establishes a need to delay implementation; and</P>
                            <P>(B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>
                                (2) 
                                <E T="03">Exemption.</E>
                                 (i) A State operating a separate CHIP in which at least 90 percent of the State's CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in § 457.10, may request an exemption for its fee-for-service program from either or both of the following requirements:
                            </P>
                            <P>(A) Paragraph (a) of this section.</P>
                            <P>(B) Paragraphs (b)(1) and (3) through (7) of this section.</P>
                            <P>(ii) The State's exemption request must:</P>
                            <P>(A) Be submitted in writing as part of a State's annual APD for MMIS operations expenditures before the compliance date for the requirements to which the State is seeking an exemption.</P>
                            <P>(B) Include both of the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Documentation that the State meets the threshold for the exemption, based on enrollment data from section 5 of the most recently accepted CHIP Annual Report Template System (CARTS).
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
                            </P>
                            <P>(iii) CMS grants the exemption if the State establishes to CMS's satisfaction that the State—</P>
                            <P>(A) Meets the threshold for the exemption; and</P>
                            <P>(B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.</P>
                            <P>(iv) The State's exemption expires if either—</P>
                            <P>(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and fee-for-service enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or</P>
                            <P>
                                (B)(
                                <E T="03">1</E>
                                ) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and fee-for-service enrollment data.
                            </P>
                            <P>(v) If a State's exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following:</P>
                            <P>(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CARTS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to fee-for-service enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold.</P>
                            <P>(B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section within 2 years of the expiration of the exemption.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>28. Section 457.732 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.732</SECTNO>
                            <SUBJECT>Prior authorization requirements.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Communicating a reason for denial.</E>
                                 Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of drugs as defined in § 457.730(b)(6)), in accordance with the timeframes established in § 457.495(d), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Prior Authorization Application Programming Interface (API).</E>
                                 Unless granted an extension or exemption under paragraph (d) of this section, beginning January 1, 2027, a State must implement and maintain an API conformant with § 457.730(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that—
                            </P>
                            <P>
                                (1) Is populated with the State's list of covered items and services (excluding 
                                <PRTPAGE P="8985"/>
                                drugs as defined in § 457.730(b)(6)) that require prior authorization;
                            </P>
                            <P>(2) Can identify all documentation required by the State for approval of any items or services that require prior authorization;</P>
                            <P>(3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and</P>
                            <P>(4) Communicates the following information about prior authorization requests:</P>
                            <P>(i) Whether the State—</P>
                            <P>(A) Approves the prior authorization request (and the date or circumstance under which the authorization ends);</P>
                            <P>(B) Denies the prior authorization request; or</P>
                            <P>(C) Requests more information.</P>
                            <P>(ii) If the State denies the prior authorization request, it must include a specific reason for the denial.</P>
                            <P>
                                (c) 
                                <E T="03">Publicly reporting prior authorization metrics.</E>
                                 Beginning in 2026, a State must annually report prior authorization data, excluding data on drugs as defined in § 457.730(b)(6), at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting them on its website:
                            </P>
                            <P>(1) A list of all items and services that require prior authorization.</P>
                            <P>(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                            <P>(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                            <P>(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(8) The average and median time that elapsed between the submission of a request and a determination by the State, for standard prior authorizations, aggregated for all items and services.</P>
                            <P>(9) The average and median time that elapsed between the submission of a request and a decision by the State for expedited prior authorizations, aggregated for all items and services.</P>
                            <P>
                                (d) 
                                <E T="03">Extensions and exemptions</E>
                                —(1) 
                                <E T="03">Extension.</E>
                                 (i) A State may submit a written application to request a one-time, 1-year extension of the requirements in paragraph (b) of this section for its CHIP fee-for-service program. The written application must be submitted and approved as part of the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures described in part 433, subpart C, of this chapter, and approved before the compliance date in paragraph (b) of this section. It must include all the following:
                            </P>
                            <P>(A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program;</P>
                            <P>(B) A report on completed and ongoing State activities that evidence a good faith effort toward compliance.</P>
                            <P>(C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>(ii) CMS grants the State's request if it determines, based on the information provided, that—</P>
                            <P>(A) The request adequately establishes a need to delay implementation; and</P>
                            <P>(B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.</P>
                            <P>
                                (2) 
                                <E T="03">Exemption.</E>
                                 (i) A State operating a separate CHIP in which at least 90 percent of the State's CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in § 457.10, may request an exemption for its fee-for-service program from the requirements in paragraph (b) of this section.
                            </P>
                            <P>(ii) The State's exemption request must:</P>
                            <P>(A) Be submitted in writing as part of a State's annual APD for MMIS operations expenditures before the compliance date in paragraph (b) of this section.</P>
                            <P>(B) Include both of the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Documentation that the State meets the threshold for the exemption, based on enrollment data from section 5 of the most recently accepted CARTS.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
                            </P>
                            <P>(iii) CMS grants the exemption if the State establishes to CMS's satisfaction that the State—</P>
                            <P>(A) Meets the threshold for the exemption; and</P>
                            <P>(B) Has established an alternative plan to ensure that its enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.</P>
                            <P>(iv) The State's exemption expires if either—</P>
                            <P>(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and fee-for-service enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or</P>
                            <P>
                                (B)(
                                <E T="03">1</E>
                                ) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and fee-for-service enrollment data.
                            </P>
                            <P>(v) If a State's exemption expires under paragraph (d)(2)(iv) of this section, the State is required to do both of the following:</P>
                            <P>(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CARTS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to fee-for-service enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold.</P>
                            <P>(B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (b) of this section within 2 years of the expiration of the exemption.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>29. Section 457.1206 is amended by revising paragraph (b)(6) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.1206</SECTNO>
                            <SUBJECT>Non-emergency medical transportation PAHPs.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(6) The PAHP standards in § 438.206(b)(1) of this chapter, as cross-referenced by §§ 457.1230(a) and (d) and 457.1233(a), (b), and (d), excluding the requirement in § 438.242(b)(7) of this chapter to comply with § 431.61(a) of this chapter.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>30. Section 457.1230 is amended by revising paragraph (d) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.1230</SECTNO>
                            <SUBJECT>Access standards.</SUBJECT>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Coverage and authorization of services.</E>
                                 The State must ensure, through its contracts, that each MCO, PIHP, or PAHP complies with the coverage and authorization of services requirements in accordance with the terms of § 438.210 of this chapter, except that the following do not apply:
                                <PRTPAGE P="8986"/>
                            </P>
                            <P>(1) Section 438.210(a)(5) of this chapter (related to medical necessity standard).</P>
                            <P>(2) Section 438.210(b)(2)(iii) of this chapter (related to authorizing long term services and supports (LTSS)).</P>
                        </SECTION>
                    </REGTEXT>
                    <HD SOURCE="HD1">TITLE 45—Public Welfare</HD>
                    <PART>
                        <HD SOURCE="HED">PART 156-HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="156">
                        <AMDPAR>31. The authority citation for part 156 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="156">
                        <AMDPAR>32. Section 156.221 is amended by—</AMDPAR>
                        <AMDPAR>a. In paragraph (b)(1)(ii), removing the word “and” at the end of the paragraph;</AMDPAR>
                        <AMDPAR>b. Revising paragraph (b)(1)(iii);</AMDPAR>
                        <AMDPAR>c. Adding paragraphs (b)(1)(iv) and (v); and</AMDPAR>
                        <AMDPAR>d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (i).</AMDPAR>
                        <P>The revisions and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 156.221</SECTNO>
                            <SUBJECT>Access to and exchange of health data and plan information.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(1) * * *</P>
                            <P>(iii) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the Qualified Health Plan (QHP) issuer no later than 1 business day after the QHP issuer receives the data; and</P>
                            <P>(iv) For plan years beginning on or after January 1, 2027, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined in paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section.</P>
                            <P>(A) The prior authorization request and decision, including all of the following, as applicable:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The prior authorization status.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The date the prior authorization was approved or denied.
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) The date or circumstance under which the prior authorization ends.
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) The items and services approved.
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) If denied, a specific reason why the request was denied.
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Related structured administrative and clinical documentation submitted by a provider.
                            </P>
                            <P>(B) The information in paragraph (b)(1)(iv)(A) of this section must—</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Be accessible no later than 1 business day after the QHP issuer receives a prior authorization request;
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Be updated no later than 1 business day after any status change; and
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.
                            </P>
                            <P>(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the QHP issuer.</P>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);</P>
                            <STARS/>
                            <P>(4) * * *</P>
                            <P>(ii) * * *</P>
                            <P>(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data specified in paragraph (b) of this section or §§ 156.221, 156.222, and 156.223 through the required APIs.</P>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Reporting on Patient Access API usage.</E>
                                 Beginning in 2026, by March 31 following any calendar year that it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the issuer level in the form and manner specified by the Secretary:
                            </P>
                            <P>(1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee.</P>
                            <P>(2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee.</P>
                            <STARS/>
                            <P>
                                (i) 
                                <E T="03">Applicability.</E>
                                 A QHP issuer on an individual market Federally-facilitated Exchange, not including QHP issuers offering only stand-alone dental plans, must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning with plan years beginning on or after January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data:
                            </P>
                            <P>(1) With a date of service on or after January 1, 2016; and</P>
                            <P>(2) That are maintained by the QHP issuer for enrollees in QHPs.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="156">
                        <AMDPAR>33. Section 156.222 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 156.222</SECTNO>
                            <SUBJECT>Access to and exchange of health data for providers and payers.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application programming interface to support data exchange from payers to providers—Provider Access API.</E>
                                 Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2027, QHP issuers on a Federally-facilitated Exchange must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an application programming interface (API) conformant with all of the following:
                            </P>
                            <P>(i) Section 156.221(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Provider access.</E>
                                 Make the data specified in § 156.221(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that are maintained by the QHP issuer to available in-network providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:
                            </P>
                            <P>(i) The QHP issuer authenticates the identity of the provider that requests access and attributes the enrollee to the provider under the attribution process described in paragraph (a)(3) of this section.</P>
                            <P>(ii) The enrollee does not opt out as described in paragraph (a)(4) of this section.</P>
                            <P>(iii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (3) 
                                <E T="03">Attribution.</E>
                                 Establish and maintain a process to associate enrollees with their in-network providers to enable data exchange via the Provider Access API.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Opt out and patient educational resources.</E>
                                 (i) Establish and maintain a process to allow an enrollee or the enrollee's personal representative to opt out of data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the QHP issuer makes enrollee information available via the Provider Access API and at any time while the enrollee is enrolled with the QHP issuer.
                            </P>
                            <P>
                                (ii) Provide information to enrollees in plain language about the benefits of 
                                <PRTPAGE P="8987"/>
                                API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows:
                            </P>
                            <P>(A) Before the first date on which the QHP issuer makes enrollee information available through the Provider Access API.</P>
                            <P>(B) No later than 1 week after the after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later.</P>
                            <P>(C) At least annually.</P>
                            <P>(D) In an easily accessible location on its public website.</P>
                            <P>
                                (5) 
                                <E T="03">Provider resources.</E>
                                 Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting enrollee data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the QHP issuer's attribution process to associate enrollees with their providers.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Application programming interface to support data exchange between payers—Payer-to-Payer API.</E>
                                 Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2027, QHP issuers on a Federally-facilitated Exchange must do the following:
                            </P>
                            <P>
                                (1) 
                                <E T="03">API requirements.</E>
                                 Implement and maintain an API conformant with all of the following:
                            </P>
                            <P>(i) Section 156.221(c)(2) through (4), (d), and (e).</P>
                            <P>(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).</P>
                            <P>
                                (2) 
                                <E T="03">Opt in.</E>
                                 Establish and maintain a process to allow enrollees or their personal representatives to opt into the QHP issuer's payer to payer data exchange with the enrollee's previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time.
                            </P>
                            <P>(i) The opt in process must be offered as follows:</P>
                            <P>(A) To current enrollees, no later than the compliance date.</P>
                            <P>(B) To new enrollees, no later than 1 week after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later.</P>
                            <P>(ii) If an enrollee does not respond or additional information is necessary, the QHP issuer must make reasonable efforts to engage with the enrollee to collect this information.</P>
                            <P>
                                (3) 
                                <E T="03">Identify previous and concurrent payers.</E>
                                 Establish and maintain a process to identify a new enrollee's previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows:
                            </P>
                            <P>(i) For current enrollees, no later than the compliance date.</P>
                            <P>(ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later.</P>
                            <P>(iii) If an enrollee does not respond or additional information is necessary, the QHP issuer must make reasonable efforts to engage with the enrollee to collect this information.</P>
                            <P>
                                (4) 
                                <E T="03">Exchange request requirements.</E>
                                 Exchange enrollee data with other payers, consistent with the following requirements:
                            </P>
                            <P>(i) The QHP issuer must request the data specified in paragraph (b)(4)(ii) of this section through the enrollee's previous payers' API, if all the following conditions are met:</P>
                            <P>(A) The enrollee has opted in, as described in paragraph (b)(2) of this section.</P>
                            <P>(B) The exchange is not prohibited by other applicable law.</P>
                            <P>(ii) The data to be requested are all of the following with a date of service within 5 years before the request:</P>
                            <P>(A) Data specified in § 156.221(b) excluding the following:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Provider remittances and enrollee cost-sharing information.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Denied prior authorizations.
                            </P>
                            <P>(B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations.</P>
                            <P>(iii) The QHP issuer must include an attestation with this request affirming that the enrollee is enrolled with the QHP issuer and has opted into the data exchange.</P>
                            <P>(iv) The QHP issuer must complete this request as follows:</P>
                            <P>(A) No later than 1 week after the payer has sufficient identifying information about previous payers and the enrollee has opted in.</P>
                            <P>(B) At an enrollee's request, within 1 week of the request.</P>
                            <P>(v) The QHP issuer must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the enrollee, any data made available by other payers in response to the request.</P>
                            <P>
                                (5) 
                                <E T="03">Exchange response requirements.</E>
                                 Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the QHP issuer to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met:
                            </P>
                            <P>(i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange.</P>
                            <P>(ii) Disclosure of the data is not prohibited by other applicable law.</P>
                            <P>
                                (6) 
                                <E T="03">Concurrent coverage data exchange requirements.</E>
                                 When an enrollee has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a QHP issuer on a Federally-facilitated Exchange must do the following, through the API required in paragraph (b)(1) of this section:
                            </P>
                            <P>(i) Request the enrollee's data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled with both payers.</P>
                            <P>(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the QHP issuer may exclude any data that were previously sent to or originally received from the concurrent payer.</P>
                            <P>
                                (7) 
                                <E T="03">Patient educational resources.</E>
                                 Provide information to enrollees in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The QHP issuer must provide the following resources:
                            </P>
                            <P>(i) When requesting an enrollee's permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section.</P>
                            <P>(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees.</P>
                            <P>(iii) In an easily accessible location on its public website.</P>
                            <P>
                                (c) 
                                <E T="03">Exception.</E>
                                 (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section, the issuer must include a narrative justification in its QHP application that describes all of the following:
                            </P>
                            <P>(i) The reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year.</P>
                            <P>(ii) The impact of non-compliance upon providers and enrollees.</P>
                            <P>(iii) The current or proposed means of providing health information to payers.</P>
                            <P>(iv) Solutions and a timeline to achieve compliance with the requirements in paragraph (a) or (b) of this section (or paragraphs (a) and (b)).</P>
                            <P>
                                (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section if 
                                <PRTPAGE P="8988"/>
                                the Exchange determines that making QHPs of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and an exception is warranted to permit the issuer to offer QHPs through the FFE.
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="156">
                        <AMDPAR>34. Section 156.223 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 156.223</SECTNO>
                            <SUBJECT>Prior authorization requirements.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Communicating a reason for denial.</E>
                                 Beginning January 1, 2026, if the QHP issuer denies a prior authorization request (excluding a request for coverage of drugs as defined in § 156.221(b)(1)(v)), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Prior Authorization Application Programming Interface (API).</E>
                                 Unless granted an exception under paragraph (d) of this section, for plan years beginning on or after January 1, 2027, a QHP issuer on a Federally-facilitated Exchange must implement and maintain an API conformant with § 156.221(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that—
                            </P>
                            <P>(1) Is populated with the QHP issuer's list of covered items and services (excluding drugs as defined in § 156.221(b)(1)(v)) that require prior authorization;</P>
                            <P>(2) Can identify all documentation required by the QHP issuer for approval of any items or services that require prior authorization;</P>
                            <P>(3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and</P>
                            <P>(4) Communicates the following information about prior authorization requests:</P>
                            <P>(i) Whether the QHP issuer—</P>
                            <P>(A) Approves the prior authorization request (and the date or circumstance under which the authorization ends);</P>
                            <P>(B) Denies the prior authorization request; or</P>
                            <P>(C) Requests more information.</P>
                            <P>(ii) If the QHP issuer denies the prior authorization request, it must include a specific reason for the denial.</P>
                            <P>
                                (c) 
                                <E T="03">Publicly reporting prior authorization metrics.</E>
                                 Beginning in 2026, following each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must report prior authorization data, excluding data on drugs as defined in § 156.221(b)(1)(v), at the issuer level by March 31. The QHP issuer must make the following data from the previous calendar year publicly accessible by posting them on its website:
                            </P>
                            <P>(1) A list of all items and services that require prior authorization.</P>
                            <P>(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.</P>
                            <P>(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.</P>
                            <P>(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.</P>
                            <P>(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.</P>
                            <P>(8) The average and median time that elapsed between the submission of a request and a determination by the QHP issuer, for standard prior authorizations, aggregated for all items and services.</P>
                            <P>(9) The average and median time that elapsed between the submission of a request and a decision by the QHP issuer for expedited prior authorizations, aggregated for all items and services.</P>
                            <P>
                                (d) 
                                <E T="03">Exception.</E>
                                 (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (b) of this section, the issuer must include a narrative justification in its QHP application that describes all of the following:
                            </P>
                            <P>(i) The reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year.</P>
                            <P>(ii) The impact of non-compliance upon providers and enrollees.</P>
                            <P>(iii) The current or proposed means of providing health information to providers.</P>
                            <P>(iv) Solutions and a timeline to achieve compliance with the requirements in paragraph (b) of this section.</P>
                            <P>(2) The Federally-facilitated Exchange (FFE) may grant an exception to the requirements in paragraph (b) of this section if the Exchange determines that making QHPs of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates and an exception is warranted to permit the issuer to offer QHPs through the FFE.</P>
                        </SECTION>
                    </REGTEXT>
                    <SIG>
                        <NAME>Xavier Becerra,</NAME>
                        <TITLE>Secretary, Department of Health and Human Services.</TITLE>
                    </SIG>
                </SUPLINF>
                <FRDOC>[FR Doc. 2024-00895 Filed 1-18-24; 4:15 pm]</FRDOC>
                <BILCOD>BILLING CODE 4150-28-P</BILCOD>
            </RULE>
        </RULES>
    </NEWPART>
</FEDREG>
